Category Archives: Redes

Funcionalidade de Stateful Firewall em Roteadores Cisco: yes, we can !!

Na primeira vez que ouvem sobre a possibilidade de implementar soluções de stateful firewall em roteadores, muitos administradores de Segurança demonstram imediata desconfiança…

Por um lado acho compreensível, visto que os roteadores são, por excelência, elementos provedores de conectividade, não impondo restrições para encaminhamento de pacotes (basta que conheçam a rota para o destino de interesse). Vale ainda lembrar que a operação padrão de roteamento tem natureza stateless, já que os pacotes são roteados como entidades individualizadas ( e não como parte de uma conexão).

Entendo ainda que em pontos específicos da rede, tais como Data Center e borda Internet, não é uma prática recomendável apostar todas as fichas em um elemento só.

Mas o que pensar sobre implementar a funcionalidade de stateful firewall em roteadores que atendem localidades remotas e que, tipicamente, não apresentam requisitos elevados de desempenho ? Seria possível ter um firewall de verdade em um tal roteador ? (- Sem dúvida… Caso contrário, nã0 me atreveria a escrever este post… 😉 )

Começo a responder tais perguntas, afirmando que a funcionalidade integrada de stateful firewall não é novidade nos roteadores Cisco. O modelo Context Based Access Control (CBAC), também conhecido como Classic IOS Firewall está disponível há mais de dez anos e o seu sucessor, Zone-based Policy Firewall (ZFW), ilustrado na Figura 1,  há pelo menos seis…

Figura 1: Visão Geral do conceito de “Security Zone”

Neste ponto da discussão você pode estar se perguntando:

Se já existia o CBAC, por que criar o Zone-based Firewall ? O CBAC não era suficiente ?

Bem, vamos à análise:

  • A abordagem CBAC já provia um firewall stateful mas as regras de inspeção eram criadas entre pares de interfaces, não havendo um conceito de “domínio de segurança” (Security Zone, utilizando a nomenclatura do ZFW). Tal característica dificultava a visualização lógica das relações de confiança entre os elementos da topologia e também trazia desafios em termos de expansibilidade. Imagine, por exemplo, criar regras entre dez interfaces distintas ou estabelecer uma política que controle o acesso entre as interfaces Giga 1/1.200  e Giga 1/2.25… (É fácil perceber que uma política INISIDE>OUTSIDE é algo bem mais intuitivo…)
  •  A linha de raciocínio de construção de políticas adotada pelo ZFW é muito similar à que se usa para configurar Qualidade de Serviço (class-map para classificar pacotes e policy-map para definir as ações a serem tomadas para o tráfego classificado) e, portanto, para os que já estão acostumados com QoS, assimilar os conceitos do ZFW será mais simples. (A estrutura de configuração é mostrada na Figura 2).
  • O modelo proposto pelo Zone-based Policy Firewall permite que o roteador seja configurado de modo a bloquear por default, fato este que o aproxima em comportamento dos appliances de segurança dedicados. Após este passo inicial de “fechar” o roteador, você pode definir os critérios para que os pacotes sejam encaminhados entre duas dadas interfaces (que agora são membros de Security Zones). E teríamos, assim, uma espécie de encaminhamento condicional: além de dispor da rota para o destino, a criação daquela conexão específica deve estar prevista na política de firewall em vigor.

Figura 2: Estrutura de uma política de acesso do Zone-based Firewall

Alguns fatos adicionais merecem especial menção:

  1. O ZFW é a abordagem que vem recebendo todos os investimentos no que concerne a evolução funcional. Só convém usar o CBAC em roteadores muito antigos cujo IOS não suporte o novo modelo.
  2. O ZFW está disponível nas imagens Security do Cisco IOS, juntamente com as funcionalidades de VPN. Desta forma, se você comprou tal imagem por precisar da conectividade segura materializada pelas soluções de VPN,  a boa notícia é que ganhou um stateful firewall de brinde ! 🙂 ( E reciprocamente…)
  3. Os roteadores ISR (Integrated Services Routers), os quais já provêem uma miríade de opções de conectividade e serviços (switching, WLAN, Multicast, Telefonia IP/VoIP, backup via GSM/CDMA/DSL, etc) podem agora ser configurados como gateways condicionais (tanto em modo roteado como modo transparente), o que os torna ainda mais completos e flexíveis.
  4. Nunca é demais enfatizar que as listas de controle de acesso (ACLs) empregadas numa política ZFW são de natureza stateful e, portanto, vão muito além de meros filtros de pacotes.

Termino este breve post, propondo que você estude mais a respeito do Cisco Zone-based Policy Firewall para que possa contar com tal recurso em seus projetos que envolvem os roteadores Cisco ISR. Para facilitar o acesso a informações sobre o tema, produzi uma série de artigos e, naturalmente, espero que o material seja útil. (É importante observar, no entanto, que a página do blog mostra os posts mais recentes primeiro… Vale a pena começar pelos “older posts“…)

*** Nota:

Também é relevante se informar sobre a facilidade de se montar INTRANETS seguras com a tecnologia GET VPN:

*** Leitura Adicional:

Leave a comment

Filed under Português, Redes, Segurança

Segurança para Comunicações Unificadas: o que esperar do seu Firewall ?

Em um artigo anterior, apresentamos os conceitos básicos de VoIP, Telefonia IP e Colaboração (http://wp.me/p1loe7-c2) e caracterizamos o papel das redes convergentes como plataforma de negócios. Não é necessária uma longa reflexão para concluir que um tal apelo negocial vem acompanhado da necessidade de se prover segurança para o transporte integrado de vídeo, voz e dados.

Seguindo o clássico raciocínio de que é recomendável criar “camadas de segurança”, resumimos a seguir algumas iniciativas relevantes no que concerne à Segurança de Telefonia IP:

  • Separação das VLANs de voz e dados nas portas de acesso dos switches LAN (usando o conceito de “Voice VLAN“)
  • Prover proteção contra as técnicas que podem induzir um redirecionamento de tráfego em ambientes de switches LAN (mesmo sem necessidade de configuração explícita de espelhamento de portas). Exemplos de ataques em um tal categoria são ARP Cache Poisoning (combatido com Dynamic ARP Inspection) e emulação do servidor DHCP (combatido com DHCP Snooping).
  • Controle de acesso entre subredes associadas a voz e dados.
  • Criptografia da voz para evitar a remontagem das conversações eventualmente capturadas
  • Proteção dos servidores que implementam as soluções de colaboração usando firewalls
  • Proteção das entidades de sinalização (Call Managers, gateways, gatekeepers, etc) por meio de firewalls.

A discussão de todas as técnicas que acabamos de elencar exigiria muitos artigos e, portanto, concentraremos nossa atenção na última delas. E uma das motivações para uma tal escolha é precisamente esclarecer o significado da expressão “inspeção avançada dos protocolos de telefonia“, sempre presente nos descritivos técnicos dos firewalls disponíveis no mercado (mas quase nunca detalhados).

A esta altura, alguém que já conheça os princípios básicos de segurança de redes pode estar se perguntando: ” – Se voz e vídeo são apenas novas aplicações que usam o transporte convergente, por que precisariam de um tratamento especial ao atravessar um firewall…? A resposta está relacionada à forma com que os protocolos de sinalização de Telefonia IP (que podem usar transporte TCP ou UDP) negociam as portas UDP destinadas aos canais de mídia (RTP/RTCP):

  • Se os firewalls inseridos entre os elementos de sinalização não entenderem perfeitamente a natureza do protocolo em uso (SCCP, SIP, H.323 ou MGCP), não serão capazes de criar corretamente as conexões RTP/RTCP. E, bem sabemos, deixar um intervalo de portas UDP previamente aberto não é uma boa idéia se você tem intenção de implementar uma política de firewall que tenha alguma dignidade… 🙂
  • Apesar de sempre mencionarmos a criação das conexões, também é vital (tanto sob a ótica de segurança como de liberação de recursos) que elas sejam terminadas dinamicamente. Para materializar tal possibilidade é importante que o firewall suporte timeouts diferenciados para as sessões de controle e mídia.
  • Os protocolos de sinalização de voz tipicamente incluem o endereço IP em seu payload (camada de aplicação). Desta forma, caso as comunicações se estabeleçam em ambientes com NAT ou PAT, é fundamental que o firewall tenha consciência de tais características para que possa efetuar as traduções de endereços IP nas camadas 3 e 7 simultaneamente.
  • Um dos atrativos de Telefonia IP é a capacidade de prover confidencialidade para a voz transportada, usando, por exemplo, sinalização sobre TLS (Transport Layer Security) para então derivar os canais Secure RTP (SRTP) para mídia (vide figura 3). O desafio em uma tal situação é que muitos firewalls não conseguem entender a sinalização cifrada e teriam, portanto, que deixar um grande número de portas UDP (associadas ao SRTP) abertas. Isso, em termos práticos, significa abrir mão da criptografia de voz ou do stateful firewall.

Para auxiliar na compreensão dos principais conceitos da integração de firewalls a projetos de UC , passaremos agora à análise de alguns modelos de topologia: um primeiro, contendo apenas telefones IP, e um mais abrangente, prevendo a existência de gateways de voz e comunicação com a rede pública de telefonia (PSTN). Por último (Figura 3), examinaremos a situação de agregar criptografia a fluxos de voz que atravessam o firewall.

A Figura 1 ilustra um cenário simples em que dois IP Phones SCCP (Skinny), que residem em  redes diferentes, precisam se comunicar em uma topologia protegida por um Cisco ASA. A figura caracteriza a situação inicial (apenas sinalização) e um momento seguinte, com uma ligação estabelecida. (Note que o firewall identifica claramente as portas associadas a áudio). Para fins práticos, vale citar que, além da permissão para registro dos telefones e execução de chamadas (porta de serviço TCP/2000 na direção do telefone ao CUCM ), você precisará criar regras que permitam o uso dos serviços auxiliares:

  • TFTP (dos telefones para o CUCM): neste caso, as atribuições principais do servidor TFP são a transferência de arquivos de firmware e configuração para os telefones.
  • Resolução DNS do nome do CUCM ( e eventuais serviços complementares).
  • DHCP é a escolha tradicional para endereçamento dos IP phones. A opção DHCP 150 informa os telefones sobre o endereço IP do servidor TFTP. Tal funcionalidade pode ser habilitada por interface no próprio Cisco ASA.

Figura 1: Cenário simples usando sinalização SCCP (Skinny)

Há ambientes com complexidade bem superior ao que foi mostrado na Figura 1, exigindo alta capacidade de coordenação por parte do firewall. Isso costuma ocorrer porque, mesmo depois de ter migrado toda a sua rede para telefonia IP, você ainda precisará integrá-la com as redes tradicionais de telefonia, fato este que exige a inclusão dos gateways de voz . Se você estiver usando o conjunto de padrões H.323, por exemplo, a primeira tarefa adicional é decidir se os gateways se comunicarão diretamente com o CUCM ou se haverá o uso de um gatekeeper.

Dentre os protocolos definidos no framework H.323, alguns são de particular relevância para redes VoIP/IPT:

  • H.225: responsável por criação e finalização de chamadas em ambientes H.323. As mensagens H.225 usam a porta TCP/1720.
  • H.245: responsável por flow control, negociação de funcionalidades e alocação dos canais de mídia, dentre outras atividades. A porta TCP usada para o H.245 é derivada da inspeção H.225.
  • H.225 RAS: As mensagens de Registration, Admission and Status (RAS) são usadas nos ambientes em que o roteamento de chamadas de voz é executado de forma centralizada por um gatekeeper H.323. A porta UDP/1719 é reservada para o RAS.

Os dois modelos H.323 brevemente descritos são ilustrados na Figura 2. A principal razão para incluir tal exemplo está relacionada com a tentativa de enfatizar que o firewall deve ser capaz de analisar as várias etapas de sinalização e manter o processo de chamadas o mais transparente possível para os usuários finais.  Note que há várias entidades de sinalização envolvidas (CUCM, gateways, gatekeeper), as quais normalmente estão situadas em diferentes interfaces do firewall. Além disso, o objetivo final (após inspecionar as várias mensagens de controle) é estabelecer a chamada entre os telefones (os quais também podem estar localizados em interfaces diferentes).

Cumpre ainda ressaltar que o Cisco Unified Communications Manager (CUCM) pode operar simultaneamente como controlador de chamadas que usem qualquer dos protocolos mencionados (SCCP, SIP, H.323 e MGCP), o que permite seu uso como elemento de interworking entre tais tecnologias. Mais interessante ainda é o fato de o Cisco ASA poder ser incorporado a um tal cenário sem qualquer perda de funcionalidade.

Figura 2: Inserção do firewall em ambientes com H.323

A Figura 3 traz um cenário que envolve troca de sinalização sobre TLS (TCP 2443 para SCCP/TLS ou TCP/5061 para SIP/TLS) e posterior estabelecimento do canal SRTP através do firewall. Basicamente, o firewall se apresenta como CUCM para os telefones (usando os certificados apropriados) e simula ser um telefone para o CUCM. Após criação de tais relações de confiança, os telefones podem se registrar de forma segura e criar as sessões SRTP pertinentes.

Lembrando que as chaves para criptografia de voz são geradas durante o processo de sinalização, usar mensagens de controle em clear text não é uma abordagem conveniente. (Daí o fato de se recorrer ao transporte sobre TLS).

Figura 3: Criptografia de voz (SRTP) em ambientes com stateful firewalls

Para sintetizar o que foi exposto até aqui, achei interessante criar uma espécie de resumo sobre o que não pode faltar no seu firewall para telefonia, usando como exemplo o protocolo SIP (pois sua tendência de adoção é crescente):

  • A partir da análise da sinalização SIP entre o controlador de chamadas IP (Call Manager)  e os telefones IP,  devem ser criadas dinamicamente as permissões pertinentes para o tráfego de mídia (RTP/RTCP) entre os telefones envolvidos.
  • Deve ser possível configurar timeouts distintos para a conexão de sinalização SIP e para as conexões de mídia dinamicamente negociadas (RTP/RTCP).
  •  A inspeção stateful da sinalização SIP deve estar igualmente disponível para TCP e UDP.
  • O firewall deve ser capaz de analisar os pacotes de manutenção do canal de controle (keepalives) de modo a garantir que a conexão de sinalização não necessite ser restabelecida a cada chamada.
  • Deve ser possível especificar os métodos SIP (SIP Methods) aceitáveis e bloquear requisições de conexão que utilizem métodos indesejáveis.
  • Deve ser possível analisar conexões de sinalização criprografadas (SIP over TLS), de modo que sejam criadas dinamicamente as permissões adequadas para o tráfego de mídia cifrado (Secure RTP) entre os telefones IP envolvidos.

Para ir um pouco além do que foi tratado no presente post, sugiro a leitura do texto Firewalls and UC Security (artigo que escrevi para a Cisco Support Community): https://supportforums.cisco.com/docs/DOC-24159

** Leitura Adicional:

Leave a comment

Filed under Português, Redes, Segurança

Protocolos Seguros para gerenciar sua Rede LAN

Nas comunidades de TI e Telecom é bem comum que se propague a idéia de que as disciplinas de gerenciamento e segurança de Redes são inconciliáveis (e mutuamente excludentes). Em vez de formar algum juízo de valor, entendo ser conveniente buscar soluções que mostrem que tal pessimismo não pode se perpetuar. Afinal, as redes precisam ser gerenciadas… E, se por um lado Segurança não pode ser um entrave para o gerenciamento, este último não deve inserir vulnerabilidades.

O objetivo do presente artigo é apresentar resumidamente as áreas de gerência que tipicamente estão presentes em uma rede LAN e, quando possível, mostrar versões seguras para os protocolos de Rede envolvidos (dos quais o SNMPv3, Simple Network Management Protocol versão 3, é apenas um exemplo).  Admitiremos em nossa análise o caso mais simples, isto é, o uso de um switch nível 2 na camada de acesso.

Acesso seguro à linha de comando (Command Line Interface = CLI) para fins de configuração e monitorização:

  • Usar cliente Secure Shell versão 2 (SSH) em substituição ao Telnet
  • Configurar o switch para que não aceite acesso terminal que não seja SSH
  • Usar no mínimo criptografia DES mas, se possível, optar por 3DES-168 (ou AES).
  • Controlar os comandos que podem ser executados via SSH e console física por meio do protocolo TACACS+ (autenticação, autorização e accounting de comandos).

Se você confiar as atividades de configuração e monitorização a uma interface gráfica (Graphical User Interface = GUI), convém que sejam observadas as seguintes orientações:

  • Usar HTTPS e não HTTP.
  • Definir os algoritmos criptográficos aceitáveis para a garantia de confidencialidade da sessão HTTPS. Usar no mínimo DES mas, preferencialmente, 3DES-168 (ou AES).
  • Exigir autenticação de usuário administrativo seguida de autorização e accounting dos comandos através do protocolo TACACS+.

Para transferência segura de arquivos (imagens de sistema e arquivos de configuração, por exemplo) é recomendável que se opte por SCP (Secure Copy) ou SFTP (Secure FTP) em lugar de FTP e TFTP.

Após esta breve descrição das opções de configuração e acesso a arquivos, voltemos ao SNMP…

A versão 3 do protocolo SNMP (SNMPv3) foi criada com o propósito de eliminar a visão histórica de que o significado da sigla era Security is Not My Problem. O novo modelo inclui não só autenticação individualizada (por usuário) mas também criptografia dos dados transmitidos. Lembrando que há operações do SNMP que permitem até mesmo alteração da configuração do equipamento, é fácil perceber que não convém que os dados (e muito menos a senha de acesso) sejam transferidos em claro.

Vale, no entanto, um alerta: a RFC 3414 (SNMPv3) prevê três modos possíveis de operação do protocolo, os quais são representados na Figura 1. Desses, apenas o AuthPriv contempla simultaneamente autenticação e criptografia, significando que é o único que atende nosso objetivo de gerenciar com Segurança a rede. Desta forma, se você está pensando em utilizar SNMPv3, deve verificar tanto do lado das soluções de gerência como dos elementos gerenciados, se existe suporte ao modo AuthPriv e, neste caso, quais os algoritmos criptográficos disponíveis. (Imagine um produto que suporta criptografia… Mas com chave de 5 bits… )

Figura 1: Modos de operação e exemplo de pacote SNMPv3 AuthPriv

Uma outra área relevante de gerência de Redes é o controle de sincronismo entre os equipamentos. Para se ter uma idéia da importância de se dispor de uma referência única (e confiável) de relógio, listamos algumas aplicações em que a informação de tempo é utilizada:

  •  Coerência das informações de gerenciamento
  •  Coerência do accounting de utilização dos serviços de rede (normalmente controlados via RADIUS)
  •  Coerência do accounting de acesso administrativo a equipamentos de Rede (função clássica do TACACS+)
  •  Verificação da validade de Certificados Digitais
  •  Definição de políticas de acesso baseadas em horário
  •  Verificação da validade de licenças de software vinculadas a horário
  •  Subsídio para medição confiável de parâmetros de SLA
  •  Subsídio para auditoria (desde que o processo utilizado para sincronização seja seguro…)

O protocolo clássico de sincronismo é o Network Time Protocol (NTP), o qual em sua versão 3 (RFC 1305, datada de 1997) já especificava o uso de autenticação do servidor pelo cliente através de hash MD5. Diante das aplicações que acabamos de listar para a informação de sincronismo, surge naturalmente a pergunta:  – Você, na condição de administrador de Redes ou Segurança, se sentiria confortável se os seus equipamentos de Rede aceitassem qualquer informação de tempo que lhes fosse passada ?

Diante disso, vale advertir que existe uma versão simplificada do NTP, denominada SNTP (Simple NTP), que não inclui autenticação e que, portanto, não é adequada para ambientes em que é preciso comprovar comprometimento com minimização do risco operacional e disponibilizar informações para fins de auditoria. Mais detalhes são providos na Figura 2.

Figura 2: Autenticação entre cliente e servidor NTP

O presente texto é uma tentativa de caracterizar um primeiro passo na busca do objetivo maior de se construir redes LAN mais seguras. Isso porque, apesar de existirem  várias funcionalidades específicas de Segurança de LAN (802.1x, Port Security, Private VLANs, etc), se o gerenciamento não for conduzido de forma segura, todo o resto do esforço poderá ser perdido.

** Sumário de Recomendações:

  • Acesso Remoto Seguro a CLI: SSHv2
  • Acesso Remoto via Interface Gráfica: HTTPS
  • Transferência Segura de arquivos: SCP (Secure Copy) ou SFTP (Secure FTP)
  • Monitorização e Alertas: SNMPv3 no modo AuthPriv
  • Sincronismo Seguro: NTPv3 (no mínimo) com autenticação MD5 por parte do cliente (equipamento)
  • Controle de Acesso Administrativo (autorização e accounting de comandos): TACACS+

** Notas:

  • Já existe o NTP versão 4 mas muitos produtos ainda não o implementam. Enquanto a disponibilidade do novo protocolo não se amplia, o mínimo aceitavél é o suporte à versão 3.
  • As considerações aqui feitas para um switch L2 também se aplicam a elementos que operam em camada 3 (switches L3 e roteadores).
  • Há um interessante guia de hardening de switches Cisco produzido pela NSA (National Security Agency), cuja leitura é altamanente incentivada: (http://www.nsa.gov/ia/_files/switches/switch-guide-version1_01.pdf)

** Artigos Relacionados:

5 Comments

Filed under Português, Redes, Segurança

Projetos Multilayer de Redes LAN: por que usar switches nível 2 na camada de acesso ?

Quando vejo os altos números de desempenho dos atuais switches de acesso, é difícil não me lembrar que no início de minha carreira na área de Redes, o switch de núcleo da Cisco oferecia 3,6 Gbps de backplane (valor considerado alto, à época, pois as portas de usuários eram de 10Mbps). O tempo passa, a tecnologia amadurece ( tendendo a diminuir de preço) e hoje estamos em um estágio em que é bem comum que as portas de acesso (Ethernet) nos novos projetos sejam de 1Gbps (apesar de que 100Mbps por porta continuam sendo mais do que suficientes para a grande maioria dos casos).

Tudo isso é bom mas convém ter o cuidado com a armadilha dos grandes números… Digo isso, pois noto em minhas conversas com clientes uma demasiada valorização de aspectos quantitativos (dentro daquela perspectiva cômoda do “quanto mais, melhor”), em detrimento de uma análise mais criteriosa de funcionalidades que fazem a diferença no projeto como um todo.

Percebo também uma tendência a simplificar excessivamente o assunto, provavelmente influenciada pela idéia errônea de que “para montar uma LAN é só ligar o switch e conectar os cabos“… (Antes de tirar uma tal conclusão, lembre-se que “um cabo errado pode ser a origem de um loop”…)

Existe ainda a percepção histórica de que um core L2 é rápido e uma opção correspondente com L3 seria lenta, apesar de possuir mais funcionalidades. No que concerne a uma tal visão , vale dizer que, apesar de ter sido correta muitos anos atrás (vide Figura 1), os equipamentos evoluíram de modo a tornar as taxas de encaminhamento (pps) em L2 e L3 virtualmente indiscerníveis (mas, certamente, com um custo maior associado ao último). E, graças a este progresso tecnológico, é possível agora usar L2 ou L3 conforme sejam mais adequadas para um determinada área da rede (este é o chamado design multilayer, ilustrado na Figura 2).

Figura 1: Modelos Históricos de Redes LAN

Bem, se há a intenção de produzir projetos mais consistentes, é importante um melhor entendimento do modelo de camadas (acesso, distribuição e núcleo) ou, eventualmente a combinação das duas últimas, no caso de redes menores. A orientação básica pode ser resumida na adoção de L3 para conexão da distribuição ao núcleo e L2 para ligar a distribuição ao acesso (Figura 2). Isso garante a disponibilidade, convergência rápida e isolamento providos pelo L3, sem perder a mobilidade e simplicidade do acesso L2.

Figura 2: Modelo Multilayer de Projetos de LAN

As principais motivações para adotar uma abordagem multilayer são listadas a seguir:

  • Separação funcional: cada camada desempenha um papel bem definido no conjunto da solução
  • Modularidade: há blocos de projeto bem definidos, o que facilita o entendimento da topologia lógica (incluindo plano de endereçamento e esquema de numeração de VLANs).
  • Facilidade de expansão:  quando há necessidade de acrescentar portas para usuários, não é necessário fazer um novo projeto. Se a organização em camadas foi utilizada desde o início, fica bem mais fácil acrescentar um novo bloco de acesso e prover as portas necessárias
  • Padrões de tráfego determinísticos: dado que os servidores estão centralizados e que as estações de usuários se conectam a swiches de acesso, é mais fácil prever os fluxos de aplicações e planejar a utilização dos uplinks.
  • Criação de pequenos domínios de falha: a demarcação clara da função de cada camada facilita o isolamento e a resolução de problemas.
  • Equilíbrio entre recursos L2 e L3: isso permite extrair o melhor de cada uma das tecnologias.
  • A utilização de roteamento (L3) entre distribuição e núcleo, permite balanceamento de carga, convergência rápida e maior nível de controle (limitação da topologia L2).

Algumas características relevantes da camada de acesso (nível 2):

  • Ponto de ingresso na Rede : PCs, telefones IP, impressoras, etc.
  • Controle de acesso por porta à rede deve começar aqui (IEEE 802.1x/NAC): Autenticação, Autorização e Accounting para usuários e equipamentos.
  • Funcionalidades de Segurança integradas à Rede : Port security, DHCP Snooping, Dynamic ARP Inspection, IP Source Guard, Private VLANs, apenas para citar algumas.
  • Idealmente com uplinks duplicados para a camada de distribuição (alta disponibilidade).
  • Por ser um processo fim-a-fim, QoS deve começar aqui: e deve contemplar parâmetros de nível 2 (CoS), nível 3 (DSCP) e nível 4 (portas TCP e UDP).
  • Supressão de broadcast, multicast e unknown unicast
  • IGMP Snooping, de modo a evitar que portas físicas que não contém “receivers” para um determinado grupo, recebam desnecessariamente tráfego Multicast (otimização de IP Multicast na rede de switches nível 2)
  • Otimização de Spanning Tree (IEEE 802.1D, IEEE 802.1w, IEEE 802.1S)
  • Mapeamento entre VLANs (L2) e sub-redes IP (L3). O default-gateway para os hosts em um determinada VLAN fica na camada de distribuição ou distribuição/core (no caso de um design usando o conceito de “collapsed backbone”)
  • Capacidade de identificação automática de “endpoints”, principalmente os de multimídia (LLDP e LLDP-MED)

Algumas características importantes da camada de distribuição:

  • Agregação de vários switches de acesso (para criar um “bloco de acesso” em que há mobilidade dentro de uma VLAN/subnet)
  • Uplinks para o CORE a partir de um bloco de acesso (switch de distribuição) em vez de uplinks partindo de cada switch de acesso
  • Recomenda-se o uso de “Layer 3 switching” para esta camada
  • Evita que o CORE tenha que estabelecer múltiplas adjacências e o isola em relação a problemas na camada de acesso.
  • Funcionalidades de proteção do protocolo Spanning tree (definição de STP Root Bridge, evitar que switches de acesso tentem se tornar a Root Bridge)
  • Sumários de Roteamento, convergência rápida, load sharing através de caminhos redundantes
  • HSRP (Hot Standby Router Protocol) ou VRRP (Virtual Router Redundancy Protocol) ou GLBP (Gateway Load Balancing Protocol) para redundância de “default gateway”
  • Disponibilidade e load balancing (Rapid Per-VLAN Spanning Tree, Per-VLAN 802.1w)
  • Roteamento Multicast usando protocolos PIM e IGMP (interação host <> router)
  • Listas de controle de acesso para controlar a conexão entre subnets IP.

Alguns aspectos importantes a considerar na camada de CORE :

  • Sinônimo de camada 3 no conceito multilayer
  • Representa o backbone da Rede:  interconexão dos blocos de distribuição e ligação com a WAN e o Data Center.
  • Em redes grandes, a camada de CORE é normalmente usada para evitar “full-mesh” dos switches de distribuição
  • Foco em Desempenho e Estabilidade versus complexidade— “less is more in the core
  • Camada de CORE separada ajuda a prover expansibilidade para crescimento futuro.
  • Vale a pena fazer um design de CORE que seja independente da tecnologia de conexão (GigEtherntet, 10GigEthernet, CWDM, Sonet, Dynamic Packet Transport, etc.)

Tendo discutido as características dos projetos multilayer, listamos a seguir uma série de benefícios associados ao uso de switches nível 2 na camada de acesso. Além das grandes vantagens de preço trazidas por esta opção, (particularmente pelo número de switches de acesso em um projeto ser bem maior que os das demais camadas), vale mencionar:

  • Facilidade de conexão de novos usuários ( tornando o acesso plug and play)
  • Aumento da mobilidade de usuários entre switches (isso é particularmente importante em ambientes que empregam 802.1x/NAC para atribuição dinâmica de VLAN). Aliás, o design de NAC torna-se muito mais complexo quando o acesso é L3.
  • Roteamento fora da camada de acesso. Esta função é exercida pelo switch de distribuição ou CORE. Isso diminui o número de adjacências de protocolos de roteamento e aumenta a expansibilidade da Rede.
  • O fato de não se ter roteamento no acesso também contribui para a estabilidade da rede: menor número de mudanças na topologia de roteamento e redução de recálculos por parte dos protocolos dinâmicos.
  • Multicast para os usuários é controlado via IGMP Snooping (seleção de portas físicas que vão receber tráfego multicast em uma dada subnet) e não via roteamento Multicast (o que obrigaria a criação de adjacências do protocolo PIM em cada switch de acesso). Mais uma vez, ressalte-se aqui a preocupação em reduzir complexidade e aumentar estabilidade.
  • As atividades de filtragem (através de listas de controle de acesso) se concentram um nível acima (distribuição), tornando-se, portanto, muito mais facilmente gerenciáveis.
  • Particularmente no que concerne à segregação de voz e dados, é muito mais simples fazer o controle na camada de distribuição (em vez de configurar ACLs em cada switch de acesso).

Concluímos o breve texto ressaltando que, apesar de nível 2 no acesso significar que não se usa roteamento IP em tal camada,vários  outros recursos que vão muito além do nível 2 continuam disponíveis:

  • Os switches L2 modernos dispõem de capacidade de filtragem (por meio de ACLs) que levam em conta campos do cabeçalho IP e combinações de portas de serviço (TCP/UDP).
  • As tarefas de classificação de pacotes (no contexto de Qualidade de Serviço – QoS) podem ser feitas com base em critérios como DSCP (L3), endereços IP de origem/destino, portas TCP/UDP.
  • É possível gerenciar os switches via IPv6 (sem necessidade de rotear IPv6).
  • Muitos dos switches L2 atuais podem ser configurados para responder a probes de validação de SLA (Service Level Agreement) que permitem testar operações TCP, UDP e ICMP.
  • Há vários modelos de switches L2 que permitem fácil diferenciação (e separação lógica) entre telefones IP e computadores, através do recurso de Voice VLAN.

** Artigos Relacionados:

7 Comments

Filed under Português, Redes

Voz sobre IP, Telefonia IP e Colaboração

O transporte de voz sobre uma rede de dados que se apóia no IP como protocolo de camada 3 é uma alternativa para o sistema de comutação de circuitos, tradicionalmente empregado pelas companhias telefônicas. Considerando que grande parte das empresas já realizaram investimentos significativos na criação de uma infraestrutura para comunicação de dados baseada em IP e lembrando que o custo mensal das linhas de dados é (na maioria dos casos) fixo, torna-se bastante intuitivo perceber que se conseguirmos efetuar o transporte de voz sobre tal estrutura poderemos ter uma redução expressiva nos gastos com contas telefônicas e com manutenção.

Em um mundo onde a Internet ganha mais e mais relevância no que se refere à realização de negócios e aumento de produtividade e que, inclusive por isso, vem promovendo a onipresença do protocolo IP, tal perspectiva de economia com custos de operação (cada vez mais importante para manutenção da competitividade das empresas) se mostra suficientemente convidativa para que dediquemos atenção às tecnologias de Voz sobre IP e Telefonia IP.

Cumpre salientar, no entanto, que a possibilidade de tornar real o sonho de integração das redes de voz e dados em uma plataforma multisserviços está condicionada ao fato de que se atendam algumas exigências específicas do tráfego de voz. Sendo respeitadas as restrições intrínsecas a este, como, por exemplo, a necessidade de redução dos atrasos de propagação e manipulação, a uniformização dos atrasos e a reserva de uma largura de banda, pode-se obter qualidade praticamente indiferenciável daquela a que estamos habituados no processo convencional de transporte. Interessante ainda é notar que enquanto no “velho mundo” das comunicações se exigia uma banda de 64 Kbps para um canal de voz, a nova abordagem permite o uso de cerca 16 Kbps por canal, fato este que já traz em si uma exemplificação da eficiência que pode ser obtida ao se transportar voz sobre uma rede IP.

O tratamento dado pela Cisco às soluções de VoIP e Telefonia IP faz parte de um conjunto mais amplo de recomendações que visa promover a convergência dos tráfegos de dados, voz e vídeo em uma infraestrutura de rede única e desta forma contribuir para materializar o conceito de Colaboração.

Para um melhor entendimento deste ( e de outros textos correlatos) vamos começar por definir alguns termos:

  • Voice over IP (VoIP): ao utilizar a denominação Voz sobre IP, ou resumidamente VoIP, estamos nos referindo à solução conhecida como toll-bypass, em que centrais telefônicas convencionais podem ser conectadas através da rede IP, o que se torna particularmente atrativo sob o ponto de vista econômico para ligações do tipo DDD e DDI. Para este cenário faz-se necessária a adição de placas de voz aos roteadores existentes. Note-se aqui que a voz é simplesmente transportada sobre a rede IP e que as tarefas de codificação e compressão da voz são executadas pelos roteadores com placa de voz, que neste ambiente operam como gateways entre o mundo da telefonia tradicional, representado pelos PABXs, e o mundo IP, associado aos roteadores.
  • IP Telephony (IPT): quando falamos em Telefonia IP, estamos nos referindo à implementação dos já bastante difundidos serviços e funcionalidades da telefonia tradicional, com a diferença primordial de que todo o tráfego de controle, assim como a voz propriamente dita, são transportados através de uma infraestrutura de comunicação baseada em IP. Neste novo teatro passam a figurar como atores principais os Call Managers , responsáveis pelas tarefas de processamento de chamadas, e os telefones IP (IP Phones), que se apresentam como a principal interface do usuário com a rede convergente.
  • Colaboração IP: Arquitetura centrada em viabilizar a interação entre pessoas ( e assim contribuir para o compartilhamento de informações e experiências) através de aplicações tais como webex, Cisco Jabber e Telepresença. O uso de Telefonia IP é um passo natural no caminho para a Colaboração IP.

A Figura 1 traz uma comparação visual entre os serviços VoIP e Telefonia IP.

Com base no que aqui foi exposto, podemos concluir que as soluções de Telefonia IP e VoIP são complementares e, numa análise mais cuidadosa, que a implementação de VoIP é um caminho natural de migração da telefonia tradicional para aquela baseada em IP. Isto porque os roteadores com placas de voz empregados no cenário de toll-bypass podem ser utilizados para conexão direta à PSTN no momento em que se promover a eliminação do PABX de uma dada localidade. Tal situação pode ser visualizada na Figura 2, que ilustra a coexistência das soluções de VoIP e Telefonia IP.

Figura 2: Coexistência entre VoIP e Telefonia IP

** Notas:

  1. Promovendo-se uma analogia simples com o modelo de telefonia tradicional, poder-se-á facilmente associar as funções essenciais do Call Manager àquelas do PABX convencional, devendo-se ressaltar, no entanto, que ao deslocar o plano operacional de um sistema proprietário para uma estrutura de comunicação baseada no protocolo universal IP, ganha-se notável flexibilidade. E isto de imediato se traduz na possibilidade de implementação de um número virtualmente infinito de serviços adicionais. (Afinal, a telefonia passou a ser mais uma aplicação IP…)
  2. É vital destacar que o tráfego de voz gerado pelos telefones IP é “nativamente IP”, o que equivale a dizer que após passar pelos processos iniciais de codificação e compressão (internamente aos telefones), a voz é encapsulada em datagramas IP para que possa ser então transportada através da rede.

** Artigos Relacionados:

** Para saber mais sobre o conceito de Colaboração:

http://www.cisco.com/go/collaboration

3 Comments

Filed under Português, Redes

Breve texto sobre Qualidade de Serviço (QoS)

Um termo quase sempre presente nas discussões  relativas a redes de computadores é Qualidade de Serviço (QoS). A motivação para tal prestígio tem duas vertentes, uma de ordem econômica e a outra, também bastante significativa, de natureza técnica.

No que concerne à componente econômica, podemos citar os altos custos dos circuitos WAN que, particularmente no contexto brasileiro, dificultam bastante a aquisição de mais banda para as conexões de longa distância. Dada a crescente importância  das redes como plataforma de negócios e ferramenta de produtividade, é natural que o volume de tráfego tenda sempre a aumentar, fato este que torna indispensável a existência de uma solução que proporcione a otimização dos recursos de banda disponíveis na rede WAN.

Por outro lado, os diversos tipos de tráfegos tais como voz, vídeo e dados têm exigências diferentes no que concerne à utilização de banda, sensibilidade a atrasos (‘delay’) e variação de atraso (‘jitter’) para que a sua transmissão através da rede seja considerada eficiente.

É exatamente nesta esfera definidora da natureza das aplicações, que surge a componente técnica que justifica a atenção dedicada ao QoS. Sem dúvida, fazer com que tráfegos de todas as naturezas convivam de forma harmônica e minimizar o impacto das eventuais perdas sobre os fluxos de menor importância constitui tarefa bastante desafiadora.

O fato de a rede WAN ser o domínio em que é mais facilmente visível a necessidade de aplicação de políticas de QoS, não faz com que seja prescindível a preocupação com a elaboração de políticas semelhantes para o domínio das redes locais. Aliás, o desprezo, no que diz respeito às LANs, das definições de QoS é um erro clássico que pode conduzir à degradação do desempenho de algumas aplicações, mesmo que se tenha despendido um grande esforço para a WAN. Para que seja efetivo, o modelo de QoS deve, inquestionavelmente, contemplar todo o percurso seguido pelo pacote através da rede e não simplesemente um link WAN específico.

No domínio WAN, uma técnica de enfileiramento (‘queueing’) que oferece notável flexibilidade é a chamada Low Latency Queuing (LLQ), por permitir a criação de uma fila de prioridade absoluta para o tráfego de voz (pacotes tipicamente pequenos e sensíveis a atraso), bem como a separação em classes dos  tráfegos de vídeo e dados.  Deve-se aqui ressaltar que é bem comum a criação de mais que uma classe de dados, para que a aplicação negocial crítica seja priorizada quando em contenda por recursos com serviços não essenciais.

Um ponto importante a se mencionar é que, na concepção de grande parte das pessoas, a técnica de ‘queuing’ utilizada é sinônimo de QoS. De fato, a seleção do algoritmo de enfileiramento é tarefa das mais relevantes na construção de um modelo de QoS apropriado mas, certamente, uma série de outros elementos devem ser levados em conta. Para que aplicações ‘real time’ não sejam prejudicadas, é indispensável que se lance mão de recursos como Link Fragmentation and Interleaving (LFI), compressão do cabeçalho RTP (IP RTP Header Compression) e Traffic Shaping. No caso específico de voz, a configuração de controle de admissão (Call Admission Control) também é um ponto crítico.

Além deste foco no lado WAN, também merecem atenção os recursos voltados para a garantia de QoS no domínio LAN, bem como a integração entre esses dois mundos. Deve-se ter o cuidado, por exemplo, de garantir que o tráfego:

  •     seja classificado corretamente desde o seu ponto de ingresso na rede.
  •     seja marcado com alguma identificação simples ( tal como CoS para L2 e DSCP para L3), de modo a permitir que tráfegos com necessidades semelhantes recebam tratamento adequado.
  •     seja priorizado, dentro da largura de banda associada a cada marcação, ao longo de todo o caminho entre origem e destino.

Apesar de ser um pensamento comum, não convém achar que a largura de banda em um LAN é infinita. Afinal, os problemas associados a QoS são de natureza instantânea ( e não estatística). Imagine, por exemplo, uma rede que tem ótima média de disponibilidade mas que apresenta problema de congestionamento justamente no momento em que uma transação crítica está ocorrendo…

** Artigos Relacionados:

Leave a comment

Filed under Português, Redes

INTRANETS Seguras e Expansíveis com GET VPN

O termo VPN (Virtual Private Network) é utilizado para representar tecnologias que se propõem a emular as características de uma rede privada mesmo quando os dados são transportados sobre uma infra-estrutura compartilhada.  A motivação comum às várias soluções de VPN é prover uma alternativa ecomonicamente viável aos circuitos dedicados de comunicação WAN, sem comprometer os aspectos de segurança.

Mas o termo segurança é abrangente e pode representar recursos bem distintos quando considerado sob a perspectiva de cada tecnologia analisada. As duas modalidades mais comuns de VPN (IPSec e MPLS-VPN) são otimizadas para resolver problemas complementares e possuem desafios também complementares.

A arquitetura de segurança  IPSec provê respostas para as questões de criptografia de dados, integridade, autenticação e gerenciamento de chaves criptográficas. E tudo isso é feito através de protocolos e algoritmos padronizados, fato este que a tornou uma referência quase onipresente quando o assunto é VPN. No entanto, o modelo IPSec prevê o uso de negociações ponto-a-ponto entre as partes comunicantes e encontra desafios, principalmente de roteamento, quando precisa ser implantada em larga escala.

Já o serviço MPLS-VPN provê a segmentação lógica da Rede de transporte e roteamento otimizado (any-to-any)  mas não traz qualquer definição associada à classe de disciplinas tratadas pelo framework IPSec.

Diante das capacidades expostas, consideremos agora a demanda de montar a Intranet de uma grande empresa que usa Comunicações Unificadas IP entre seus sites (interesse de tráfego any-to-any) mas que, para atender a regulamentações de seu segmento de mercado, precisa lançar mão dos benefícios providos pelo IPSec (especialmente criptografia de dados).

Em primeira análise, duas respostas simplistas poderiam ser apresentadas:

  • Montar sessões IPSec ponto-a-ponto entre cada entidade remota e o site central. Tal abordagem não seria satisfatória, pois poderia comprometer a meta de delay aceitável (150ms) para o tráfego de voz. Além disso, estaríamos abrindo mão da conectividade full-mesh que caracteriza o MPLS.
  • Configurar sessões (túneis) entre cada dois pontos remotos, de modo a evitar a passagem pela localidade central.  Além de ser praticamente ingerenciável sob o ponto-de-vista de configuração, um tal cenário ainda exigiria que cada gateway de VPN remoto (tipicamente um roteador) suportasse um número muito grande de túneis simultâneos, o que implicaria aumento de custo.

Se a mera sobreposição do IPSec ao MPLS não atende as necessidades especificadas, por que não desenvolver uma tecnologia que utilize as definições IPSec sem dispensar a conectividade otimizada provida pelo MPLS ?

Foi exatamente o que a Cisco fez… Tomando por base a RFC 3547 (Group Domain of Interpretation – GDOI) e assumindo a premissa de que para Intranets não é necessário se preocupar com a questão de esconder o endereçamento IP privado, foi criada tecnologia Group Encrypted Transport VPN (GET VPN), cujas características essenciais são elencadas a seguir:

  • Criação de Security Associations para grupos de gateways em vez do tradicional ponto-a-ponto.  Tal escolha se justifica, pois no âmbito de Intranets assume-se que os gateways VPN participantes possuem o mesmo nível de confiança. O controle de admissão de um gateway (Group Member, no contexto GET VPN) a um grupo é efetuado por uma nova entidade denominada Key Server, a qual também é responsável por distribuir, de forma centralizada, as chaves e políticas de criptografia  a serem usadas pelos membros do grupo.
  • Preservação do cabeçalho IP no pacote cifrado, sem mudar o formato do pacote IPSec (ESP) padronizado. Isso significa que um pacote criptografado com GET VPN é um caso particular de IPSec e, portanto, permite o aproveitamento de todos os algoritmos e hardwares criptográficos construídos para a tradicional tecnologia de VPN.

    GET VPN: Preservação do Cabeçalho IP

Alguns benefícios decorrem naturalmente das definições básicas de GET VPN:

  1. A preservação do cabeçalho garante que os pacotes cifrados usem o mesmo roteamento dos pacotes não-cifrados, dispensando assim a criação de uma nova camada de roteamento para o tráfego VPN.
  2. O valor do campo DSCP é automaticamente copiado para o header IP externo e, portanto,  o investimento em QoS (classificação e marcação) continua válido para o tráfego cifrado.
  3. Pode-se contabilizar a utilização da rede, por usuário, independentemente dos pacotes serem cifrados, o que representa um ganho de visibilidade em relação ao IPSec tradicional.
  4. Dado que os Group Members possuem a chave para decifrar o tráfego enviado por qualquer membro do grupo, torna-se natural e direta a distribuição de conteúdo multicast com criptografia (de forma idêntica à que se faria para tráfego não cifrado). Ressalte-se aqui que o GET VPN é a primeira tecnologia a vencer tal desafio.
  5. O gerenciamento de políticas de criptografia é bastante facilitado, pois é feito pelo Key Server de maneira centralizada. Isso é particularmente relevante para os provedeores de serviço que não mais necessitam configurar túneis VPN e definições de interesse de tráfego cifrado em centenas de equipamentos.

    Relações entre os elementos GET VPN (KS e GM)

Um aspecto crítico a se manter em mente é que um roteador habilitado para tal solução não deixa de dispor dos recursos do IPSec clássico. Pode-se empregar GET VPN para a montagem de um grupo Intranet e, ao mesmo tempo, IPSec tradicional para uma conexão Internet segura. Outro ponto relevante é que um mesmo roteador pode participar simultaneamente de vários grupos distintos, permitindo, assim que se obtenha uma solução simples de isolamento de departamentos dentro de uma mesma empresa.

Para obter mais informações sobre o assunto GET VPN, visite o portal:

http://www.cisco.com/go/getvpn

Leave a comment

Filed under Português, Redes, Segurança