Falha de Segurança no Telnet em Switches Cisco Catalyst

Olá Pessoal,

Em 17/03/2017 pp. a Cisco anunciou uma vulnerabilidade de segurança em vários switches da família Catalyst que foi descoberta a partir do vazamento recém apelidado de Vault 7, oportunidade em que mais de 8000 documentos e arquivos foram vazados no Wikileaks com detalhes de táticas e ferramentas de hacking  utilizados pela Agência Central de Inteligência (CIA) dos EUA.

O bug em questão afeta 264 switches Catalyst, 51 switches industriais Ethernet e outros 3 dispositivos, caso eles estejam executando o IOS e configurados para aceitar conexões Telnet que, convenhamos, já não deveria mais ser utilizado como protocolo de acesso remoto há anos. Segundo a Cisco, a falha estaria relacionada ao Cluster Management Protocol (CMP) no código do IOS que utiliza o Telnet internamente como protocolo de sinalização. A vulnerabilidade é que um atacante poderia explorar esse protocolo enviando opções Telnet deformadas do CMP para ganhar acesso remoto ao dispositivo e executar comandos privilegiados sem necessidade de efetuar qualquer autenticação.

Abaixo trago uma relação de todos os equipamentos afetados pela falha de segurança:

• Cisco Catalyst 2350-48TD-S Switch
• Cisco Catalyst 2350-48TD-SD Switch
• Cisco Catalyst 2360-48TD-S Switch
• Cisco Catalyst 2918-24TC-C Switch
• Cisco Catalyst 2918-24TT-C Switch
• Cisco Catalyst 2918-48TC-C Switch
• Cisco Catalyst 2918-48TT-C Switch
• Cisco Catalyst 2928-24TC-C Switch
• Cisco Catalyst 2960-24-S Switch
• Cisco Catalyst 2960-24LC-S Switch
• Cisco Catalyst 2960-24LT-L Switch
• Cisco Catalyst 2960-24PC-L Switch
• Cisco Catalyst 2960-24PC-S Switch
• Cisco Catalyst 2960-24TC-L Switch
• Cisco Catalyst 2960-24TC-S Switch
• Cisco Catalyst 2960-24TT-L Switch
• Cisco Catalyst 2960-48PST-L Switch
• Cisco Catalyst 2960-48PST-S Switch
• Cisco Catalyst 2960-48TC-L Switch
• Cisco Catalyst 2960-48TC-S Switch
• Cisco Catalyst 2960-48TT-L Switch
• Cisco Catalyst 2960-48TT-S Switch
• Cisco Catalyst 2960-8TC-L Compact Switch
• Cisco Catalyst 2960-8TC-S Compact Switch
• Cisco Catalyst 2960-Plus 24LC-L Switch
• Cisco Catalyst 2960-Plus 24LC-S Switch
• Cisco Catalyst 2960-Plus 24PC-L Switch
• Cisco Catalyst 2960-Plus 24PC-S Switch
• Cisco Catalyst 2960-Plus 24TC-L Switch
• Cisco Catalyst 2960-Plus 24TC-S Switch
• Cisco Catalyst 2960-Plus 48PST-L Switch
• Cisco Catalyst 2960-Plus 48PST-S Switch
• Cisco Catalyst 2960-Plus 48TC-L Switch
• Cisco Catalyst 2960-Plus 48TC-S Switch
• Cisco Catalyst 2960C-12PC-L Switch
• Cisco Catalyst 2960C-8PC-L Switch
• Cisco Catalyst 2960C-8TC-L Switch
• Cisco Catalyst 2960C-8TC-S Switch
• Cisco Catalyst 2960CG-8TC-L Compact Switch
• Cisco Catalyst 2960CPD-8PT-L Switch
• Cisco Catalyst 2960CPD-8TT-L Switch
• Cisco Catalyst 2960CX-8PC-L Switch
• Cisco Catalyst 2960CX-8TC-L Switch
• Cisco Catalyst 2960G-24TC-L Switch
• Cisco Catalyst 2960G-48TC-L Switch
• Cisco Catalyst 2960G-8TC-L Compact Switch
• Cisco Catalyst 2960L-16PS-LL Switch
• Cisco Catalyst 2960L-16TS-LL Switch
• Cisco Catalyst 2960L-24PS-LL Switch
• Cisco Catalyst 2960L-24TS-LL Switch
• Cisco Catalyst 2960L-48PS-LL Switch
• Cisco Catalyst 2960L-48TS-LL Switch
• Cisco Catalyst 2960L-8PS-LL Switch
• Cisco Catalyst 2960L-8TS-LL Switch
• Cisco Catalyst 2960PD-8TT-L Compact Switch
• Cisco Catalyst 2960S-24PD-L Switch
• Cisco Catalyst 2960S-24PS-L Switch
• Cisco Catalyst 2960S-24TD-L Switch
• Cisco Catalyst 2960S-24TS-L Switch
• Cisco Catalyst 2960S-24TS-S Switch
• Cisco Catalyst 2960S-48FPD-L Switch
• Cisco Catalyst 2960S-48FPS-L Switch
• Cisco Catalyst 2960S-48LPD-L Switch
• Cisco Catalyst 2960S-48LPS-L Switch
• Cisco Catalyst 2960S-48TD-L Switch
• Cisco Catalyst 2960S-48TS-L Switch
• Cisco Catalyst 2960S-48TS-S Switch
• Cisco Catalyst 2960S-F24PS-L Switch
• Cisco Catalyst 2960S-F24TS-L Switch
• Cisco Catalyst 2960S-F24TS-S Switch
• Cisco Catalyst 2960S-F48FPS-L Switch
• Cisco Catalyst 2960S-F48LPS-L Switch
• Cisco Catalyst 2960S-F48TS-L Switch
• Cisco Catalyst 2960S-F48TS-S Switch
• Cisco Catalyst 2960X-24PD-L Switch
• Cisco Catalyst 2960X-24PS-L Switch
• Cisco Catalyst 2960X-24PSQ-L Cool Switch
• Cisco Catalyst 2960X-24TD-L Switch
• Cisco Catalyst 2960X-24TS-L Switch
• Cisco Catalyst 2960X-24TS-LL Switch
• Cisco Catalyst 2960X-48FPD-L Switch
• Cisco Catalyst 2960X-48FPS-L Switch
• Cisco Catalyst 2960X-48LPD-L Switch
• Cisco Catalyst 2960X-48LPS-L Switch
• Cisco Catalyst 2960X-48TD-L Switch
• Cisco Catalyst 2960X-48TS-L Switch
• Cisco Catalyst 2960X-48TS-LL Switch
• Cisco Catalyst 2960XR-24PD-I Switch
• Cisco Catalyst 2960XR-24PD-L Switch
• Cisco Catalyst 2960XR-24PS-I Switch
• Cisco Catalyst 2960XR-24PS-L Switch
• Cisco Catalyst 2960XR-24TD-I Switch
• Cisco Catalyst 2960XR-24TD-L Switch
• Cisco Catalyst 2960XR-24TS-I Switch
• Cisco Catalyst 2960XR-24TS-L Switch
• Cisco Catalyst 2960XR-48FPD-I Switch
• Cisco Catalyst 2960XR-48FPD-L Switch
• Cisco Catalyst 2960XR-48FPS-I Switch
• Cisco Catalyst 2960XR-48FPS-L Switch
• Cisco Catalyst 2960XR-48LPD-I Switch
• Cisco Catalyst 2960XR-48LPD-L Switch
• Cisco Catalyst 2960XR-48LPS-I Switch
• Cisco Catalyst 2960XR-48LPS-L Switch
• Cisco Catalyst 2960XR-48TD-I Switch
• Cisco Catalyst 2960XR-48TD-L Switch
• Cisco Catalyst 2960XR-48TS-I Switch
• Cisco Catalyst 2960XR-48TS-L Switch
• Cisco Catalyst 2970G-24T Switch
• Cisco Catalyst 2970G-24TS Switch
• Cisco Catalyst 2975 Switch
• Cisco Catalyst 3550 12G Switch
• Cisco Catalyst 3550 12T Switch
• Cisco Catalyst 3550 24 DC SMI Switch
• Cisco Catalyst 3550 24 EMI Switch
• Cisco Catalyst 3550 24 FX SMI Switch
• Cisco Catalyst 3550 24 PWR Switch
• Cisco Catalyst 3550 24 SMI Switch
• Cisco Catalyst 3550 48 EMI Switch
• Cisco Catalyst 3550 48 SMI Switch
• Cisco Catalyst 3560-12PC-S Compact Switch
• Cisco Catalyst 3560-24PS Switch
• Cisco Catalyst 3560-24TS Switch
• Cisco Catalyst 3560-48PS Switch
• Cisco Catalyst 3560-48TS Switch
• Cisco Catalyst 3560-8PC Compact Switch
• Cisco Catalyst 3560C-12PC-S Switch
• Cisco Catalyst 3560C-8PC-S Switch
• Cisco Catalyst 3560CG-8PC-S Compact Switch
• Cisco Catalyst 3560CG-8TC-S Compact Switch
• Cisco Catalyst 3560CPD-8PT-S Compact Switch
• Cisco Catalyst 3560CX-12PC-S Switch
• Cisco Catalyst 3560CX-12PD-S Switch
• Cisco Catalyst 3560CX-12TC-S Switch
• Cisco Catalyst 3560CX-8PC-S Switch
• Cisco Catalyst 3560CX-8PT-S Switch
• Cisco Catalyst 3560CX-8TC-S Switch
• Cisco Catalyst 3560CX-8XPD-S Switch
• Cisco Catalyst 3560E-12D-E Switch
• Cisco Catalyst 3560E-12D-S Switch
• Cisco Catalyst 3560E-12SD-E Switch
• Cisco Catalyst 3560E-12SD-S Switch
• Cisco Catalyst 3560E-24PD-E Switch
• Cisco Catalyst 3560E-24PD-S Switch
• Cisco Catalyst 3560E-24TD-E Switch
• Cisco Catalyst 3560E-24TD-S Switch
• Cisco Catalyst 3560E-48PD-E Switch
• Cisco Catalyst 3560E-48PD-EF Switch
• Cisco Catalyst 3560E-48PD-S Switch
• Cisco Catalyst 3560E-48PD-SF Switch
• Cisco Catalyst 3560E-48TD-E Switch
• Cisco Catalyst 3560E-48TD-S Switch
• Cisco Catalyst 3560G-24PS Switch
• Cisco Catalyst 3560G-24TS Switch
• Cisco Catalyst 3560G-48PS Switch
• Cisco Catalyst 3560G-48TS Switch
• Cisco Catalyst 3560V2-24DC Switch
• Cisco Catalyst 3560V2-24PS Switch
• Cisco Catalyst 3560V2-24TS Switch
• Cisco Catalyst 3560V2-48PS Switch
• Cisco Catalyst 3560V2-48TS Switch
• Cisco Catalyst 3560X-24P-E Switch
• Cisco Catalyst 3560X-24P-L Switch
• Cisco Catalyst 3560X-24P-S Switch
• Cisco Catalyst 3560X-24T-E Switch
• Cisco Catalyst 3560X-24T-L Switch
• Cisco Catalyst 3560X-24T-S Switch
• Cisco Catalyst 3560X-24U-E Switch
• Cisco Catalyst 3560X-24U-L Switch
• Cisco Catalyst 3560X-24U-S Switch
• Cisco Catalyst 3560X-48P-E Switch
• Cisco Catalyst 3560X-48P-L Switch
• Cisco Catalyst 3560X-48P-S Switch
• Cisco Catalyst 3560X-48PF-E Switch
• Cisco Catalyst 3560X-48PF-L Switch
• Cisco Catalyst 3560X-48PF-S Switch
• Cisco Catalyst 3560X-48T-E Switch
• Cisco Catalyst 3560X-48T-L Switch
• Cisco Catalyst 3560X-48T-S Switch
• Cisco Catalyst 3560X-48U-E Switch
• Cisco Catalyst 3560X-48U-L Switch
• Cisco Catalyst 3560X-48U-S Switch
• Cisco Catalyst 3750 Metro 24-AC Switch
• Cisco Catalyst 3750 Metro 24-DC Switch
• Cisco Catalyst 3750-24FS Switch
• Cisco Catalyst 3750-24PS Switch
• Cisco Catalyst 3750-24TS Switch
• Cisco Catalyst 3750-48PS Switch
• Cisco Catalyst 3750-48TS Switch
• Cisco Catalyst 3750E-24PD-E Switch
• Cisco Catalyst 3750E-24PD-S Switch
• Cisco Catalyst 3750E-24TD-E Switch
• Cisco Catalyst 3750E-24TD-S Switch
• Cisco Catalyst 3750E-48PD-E Switch
• Cisco Catalyst 3750E-48PD-EF Switch
• Cisco Catalyst 3750E-48PD-S Switch
• Cisco Catalyst 3750E-48PD-SF Switch
• Cisco Catalyst 3750E-48TD-E Switch
• Cisco Catalyst 3750E-48TD-S Switch
• Cisco Catalyst 3750G-12S Switch
• Cisco Catalyst 3750G-12S-SD Switch
• Cisco Catalyst 3750G-16TD Switch
• Cisco Catalyst 3750G-24PS Switch
• Cisco Catalyst 3750G-24T Switch
• Cisco Catalyst 3750G-24TS Switch
• Cisco Catalyst 3750G-24TS-1U Switch
• Cisco Catalyst 3750G-48PS Switch
• Cisco Catalyst 3750G-48TS Switch
• Cisco Catalyst 3750V2-24FS Switch
• Cisco Catalyst 3750V2-24PS Switch
• Cisco Catalyst 3750V2-24TS Switch
• Cisco Catalyst 3750V2-48PS Switch
• Cisco Catalyst 3750V2-48TS Switch
• Cisco Catalyst 3750X-12S-E Switch
• Cisco Catalyst 3750X-12S-S Switch
• Cisco Catalyst 3750X-24P-E Switch
• Cisco Catalyst 3750X-24P-L Switch
• Cisco Catalyst 3750X-24P-S Switch
• Cisco Catalyst 3750X-24S-E Switch
• Cisco Catalyst 3750X-24S-S Switch
• Cisco Catalyst 3750X-24T-E Switch
• Cisco Catalyst 3750X-24T-L Switch
• Cisco Catalyst 3750X-24T-S Switch
• Cisco Catalyst 3750X-24U-E Switch
• Cisco Catalyst 3750X-24U-L Switch
• Cisco Catalyst 3750X-24U-S Switch
• Cisco Catalyst 3750X-48P-E Switch
• Cisco Catalyst 3750X-48P-L Switch
• Cisco Catalyst 3750X-48P-S Switch
• Cisco Catalyst 3750X-48PF-E Switch
• Cisco Catalyst 3750X-48PF-L Switch
• Cisco Catalyst 3750X-48PF-S Switch
• Cisco Catalyst 3750X-48T-E Switch
• Cisco Catalyst 3750X-48T-L Switch
• Cisco Catalyst 3750X-48T-S Switch
• Cisco Catalyst 3750X-48U-E Switch
• Cisco Catalyst 3750X-48U-L Switch
• Cisco Catalyst 3750X-48U-S Switch
• Cisco Catalyst 4000 Supervisor Engine I
• Cisco Catalyst 4000/4500 Supervisor Engine IV
• Cisco Catalyst 4000/4500 Supervisor Engine V
• Cisco Catalyst 4500 Series Supervisor Engine II-Plus
• Cisco Catalyst 4500 Series Supervisor Engine II-Plus-TS
• Cisco Catalyst 4500 Series Supervisor Engine V-10GE
• Cisco Catalyst 4500 Series Supervisor II-Plus-10GE
• Cisco Catalyst 4500 Supervisor Engine 6-E
• Cisco Catalyst 4500 Supervisor Engine 6L-E
• Cisco Catalyst 4900M Switch
• Cisco Catalyst 4928 10 Gigabit Ethernet Switch
• Cisco Catalyst 4948 10 Gigabit Ethernet Switch
• Cisco Catalyst 4948 Switch
• Cisco Catalyst 4948E Ethernet Switch
• Cisco Catalyst 4948E-F Ethernet Switch
• Cisco Catalyst Blade Switch 3020 for HP
• Cisco Catalyst Blade Switch 3030 for Dell
• Cisco Catalyst Blade Switch 3032 for Dell M1000E
• Cisco Catalyst Blade Switch 3040 for FSC
• Cisco Catalyst Blade Switch 3120 for HP
• Cisco Catalyst Blade Switch 3120X for HP
• Cisco Catalyst Blade Switch 3130 for Dell M1000E
• Cisco Catalyst C2928-24LT-C Switch
• Cisco Catalyst C2928-48TC-C Switch
• Cisco Catalyst Switch Module 3012 for IBM BladeCenter
• Cisco Catalyst Switch Module 3110 for IBM BladeCenter
• Cisco Catalyst Switch Module 3110X for IBM BladeCenter
• Cisco Embedded Service 2020 24TC CON B Switch
• Cisco Embedded Service 2020 24TC CON Switch
• Cisco Embedded Service 2020 24TC NCP B Switch
• Cisco Embedded Service 2020 24TC NCP Switch
• Cisco Embedded Service 2020 CON B Switch
• Cisco Embedded Service 2020 CON Switch
• Cisco Embedded Service 2020 NCP B Switch
• Cisco Embedded Service 2020 NCP Switch
• Cisco Enhanced Layer 2 EtherSwitch Service Module
• Cisco Enhanced Layer 2/3 EtherSwitch Service Module
• Cisco Gigabit Ethernet Switch Module (CGESM) for HP
• Cisco IE 2000-16PTC-G Industrial Ethernet Switch
• Cisco IE 2000-16T67 Industrial Ethernet Switch
• Cisco IE 2000-16T67P Industrial Ethernet Switch
• Cisco IE 2000-16TC Industrial Ethernet Switch
• Cisco IE 2000-16TC-G Industrial Ethernet Switch
• Cisco IE 2000-16TC-G-E Industrial Ethernet Switch
• Cisco IE 2000-16TC-G-N Industrial Ethernet Switch
• Cisco IE 2000-16TC-G-X Industrial Ethernet Switch
• Cisco IE 2000-24T67 Industrial Ethernet Switch
• Cisco IE 2000-4S-TS-G Industrial Ethernet Switch
• Cisco IE 2000-4T Industrial Ethernet Switch
• Cisco IE 2000-4T-G Industrial Ethernet Switch
• Cisco IE 2000-4TS Industrial Ethernet Switch
• Cisco IE 2000-4TS-G Industrial Ethernet Switch
• Cisco IE 2000-8T67 Industrial Ethernet Switch
• Cisco IE 2000-8T67P Industrial Ethernet Switch
• Cisco IE 2000-8TC Industrial Ethernet Switch
• Cisco IE 2000-8TC-G Industrial Ethernet Switch
• Cisco IE 2000-8TC-G-E Industrial Ethernet Switch
• Cisco IE 2000-8TC-G-N Industrial Ethernet Switch
• Cisco IE 3000-4TC Industrial Ethernet Switch
• Cisco IE 3000-8TC Industrial Ethernet Switch
• Cisco IE-3010-16S-8PC Industrial Ethernet Switch
• Cisco IE-3010-24TC Industrial Ethernet Switch
• Cisco IE-4000-16GT4G-E Industrial Ethernet Switch
• Cisco IE-4000-16T4G-E Industrial Ethernet Switch
• Cisco IE-4000-4GC4GP4G-E Industrial Ethernet Switch
• Cisco IE-4000-4GS8GP4G-E Industrial Ethernet Switch
• Cisco IE-4000-4S8P4G-E Industrial Ethernet Switch
• Cisco IE-4000-4T4P4G-E Industrial Ethernet Switch
• Cisco IE-4000-4TC4G-E Industrial Ethernet Switch
• Cisco IE-4000-8GS4G-E Industrial Ethernet Switch
• Cisco IE-4000-8GT4G-E Industrial Ethernet Switch
• Cisco IE-4000-8GT8GP4G-E Industrial Ethernet Switch
• Cisco IE-4000-8S4G-E Industrial Ethernet Switch
• Cisco IE-4000-8T4G-E Industrial Ethernet Switch
• Cisco IE-4010-16S12P Industrial Ethernet Switch
• Cisco IE-4010-4S24P Industrial Ethernet Switch
• Cisco IE-5000-12S12P-10G Industrial Ethernet Switch
• Cisco IE-5000-16S12P Industrial Ethernet Switch
• Cisco ME 4924-10GE Switch
• Cisco RF Gateway 10
• Cisco SM-X Layer 2/3 EtherSwitch Service Module

O relatório oficial da Cisco (CVE-2017-3881) sobre essa falha está disponível no link abaixo:

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170317-cmp

Por ora, até que uma correção de segurança seja lançada, a recomendação da Cisco é que qualquer acesso remoto via Telnet seja desativado. É fato que por várias outras razões já passou da hora de desativar o Telnet e substituí-lo pelo SSH para acesso remoto aos seus dispositivos da infraestrutura, principalmente por causa confidencialidade e autenticidade viabilizadas pela criptografia nativa do SSH. Em outro artigo do blog intitulado "Acesso Seguro ao Roteador via SSH" o leitor pode encontrar mais informações sobre como fazer essa configuração nos seus switches e roteadores.

Fiquem atentos!

Samuel. 

VPN IPSec Site-to-Site no Debian GNU/Linux

Olá Pessoal,

No Lab27 do livro Laboratórios de Tecnologias Cisco explico ao leitor como configurar dois roteadores Cisco para estabelecer uma VPN IPSec  e conectar duas redes locais (LAN) remotamente através da Internet (site-to-site). Neste artigo trago um laboratório bastante similar com base na topologia apresentada na figura abaixo, só que dessa vez irei fazê-lo através de utilização de dois servidores instalados com o Debian 8 GNU/Linux que serão configurados como roteadores VPN. 

Antes de abordar as configurações, é importante um pouco de discussão sobre a escolha de uma solução de VPN para ambientes Linux. Por se tratar de um ambiente aberto, no Linux existe uma grande diversidade de soluções que podem ser utilizadas para implementar uma VPN para fins de estabelecimento de um túnel virtual privativo entre duas (ou mais) unidades remotas. Além de existirem várias ferramentas, também existem diferentes tipos de soluções para implementação da VPN, o que faz com que o primeiro desafio de um administrador seja a escolha da solução mais adequada no contexto do seu ambiente.

As VPNs são tradicionalmente implementadas através de túneis IPSec (solução padronizada em RFC) ou de túneis SSL/TLS. As duas abordagens trazem excelentes resultados, mas é importante ter em mente que a solução IPSec é implementada em nível de rede, enquanto que a solução TLS é implementada em nível de aplicação. De maneira simplista isso quer dizer que uma VPN IPSec é implementada diretamente entre os roteadores (em nível de rede), enquanto que uma VPN TLS é implementada entre os softwares servidor/cliente (em nível de aplicação).

Cada uma dessas modalidades tem vantagens e desvantagens. Por exemplo, como a VPN TLS é estabelecida entre as aplicações (e não entre as máquinas), normalmente ela é mais atrativa para a criação de VPNs do tipo client-to-site, em que o objetivo é que um cliente em casa ou outro local fora da empresa possa se conectar aos recursos da infraestrutura de rede da empresa, afinal o próprio software cliente da máquina do usuário se encarrega de esconder do usuário toda a complexidade de configuração da VPN. Por outro lado, a principal vantagem de implementar uma VPN através do IPSec em nível de rede, ao invés do SSL em nível de aplicação, é que existe interoperabilidade entre as soluções de diferentes fabricantes.

Obs.: Reocmendo a leitura do artigo no link abaixo caso o leitor tenha interesse em estabelecer uma VPN através da integração de uma ponta que possui um roteador Cisco (baseado no IOS) e outra ponta que possui um servidor Linux Debian (baseado no strongSwan):

http://www.cisco.com/c/pt_br/support/docs/ip/internet-key-exchange-ike/117258-config-l2l.html

Particularmente neste artigo o objetivo é trazer os procedimentos de configuração de uma VPN IPSec para interconexão de duas unidades remotas de uma empresa através de um túnel virtual. Mesmo depois de tomada essa decisão, ainda existem várias ferramentas no Linux que podem ser utilizadas para esse fim, por exemplo: strongSwan, OpenSwan, LibreSwan, etc... Uma das soluções mais tradicionais é o strongSwan, já que seu desenvolvimento ainda é bastante ativo e por isso a ferramenta é repleta de novos recursos, diferente do OpenSwan que parece estar estagnado apenas para versões antigas do kernel.

Abaixo baixo trago as configurações básicas de rede que foram utilizadas em cada um dos roteadores Debian, seguindo a lógica da topologia apresentada no início do artigo. Além das configurações abaixo, também é importante alterar para 1 a flag do kernel que indica ao sistema que ele tem permissão para fazer roteamento entre redes, o que pode ser feito através do comando: sysctl -w net.ipv4.ip_forward=1

###--- Router-Site1: /etc/network/interfaces

# Interface Loopback
auto lo
iface lo inet loopack

# Conexao WAN (Internet)
auto eth0
iface eth0 inet static
    address 203.0.113.2
    netmask 255.255.255.252
    gateway 203.0.113.1

# Conexao LAN
auto eth1
iface eth1 inet static
    address 192.168.100.1
    netmask 255.255.255.0

---

###--- Router-Site2: /etc/network/interfaces

# Interface Loopback
auto lo
iface lo inet loopack

# Conexao WAN (Internet)
auto eth0
iface eth0 inet static
    address 198.51.100.2
    netmask 255.255.255.252
    gateway 198.51.100.1

# Conexao LAN
auto eth1
iface eth1 inet static
    address 192.168.200.1
    netmask 255.255.255.0

Vamos à configuração da VPN IPSec...

1) Instalação do Serviço strongSwan de VPN IPSec

Feita essa breve contextualização, vamos à instalação da ferramenta strongSwan. Assim como nos outros artigos do blog, estou considerando que os servidores estão instalados com a distribuição Debian GNU/Linux (ou seus derivados, como o Ubuntu). A primeira etapa consiste na instalação do pacote denominado strongswam para que os servidores Linux possam ser posterirmente configurados como roteadores VPN. Essa tarefa é simples e rápida através do APT:

root@Router-SiteA:/# apt-get update
root@Router-SiteA:/# apt-get install strongswan

root@Router-SiteB:/# apt-get update
root@Router-SiteB:/# apt-get install strongswan

2) Edição do Arquivo de Configuração e Definição da(s) VPN(s)

Dois dos arquivos mais importantes de configuração do strongSwan ficam localizados em /etc/ipsec.conf e /etc/ipsec.secrets.  O arquivo ipsec.conf é responsável pelas configurações gerais, além das configurações específicas de cada uma das conexões VPN. Logo, devemos editar esse arquivo em ambos os roteadores com as seguintes configurações para criar uma VPN coerente entre os pares:

###--- Router-Site1: /etc/ipsec.conf (strongSean IPSec config file)

###--- Configuracoes Gerais
config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

###--- Definicao da(s) VPN(s)
conn VPN-Site1-to-Site2
        left=203.0.113.2
        leftsubnet=192.168.100.0/24
        right=198.51.100.2
        rightsubnet=192.168.200.0/24
        ike=aes256-sha2_256-modp1024!
        esp=aes256-sha2_256!
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        authby=secret
        auto=start
        keyexchange=ikev2
        type=tunnel
     

---

###--- Router-Site2: /etc/ipsec.conf (strongSean IPSec config file)

###--- Configuracoes Gerais
config setup
        charondebug="all"
        uniqueids=yes
        strictcrlpolicy=no

###--- Definicao da(s) VPN(s)
conn VPN-Site1-to-Site2
        left=198.51.100.2
        leftsubnet=192.168.200.0/24
        right=203.0.113.2
        rightsubnet=192.168.100.0/24
        ike=aes256-sha2_256-modp1024!
        esp=aes256-sha2_256!
        keyingtries=0
        ikelifetime=1h
        lifetime=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        authby=secret
        auto=start
        keyexchange=ikev2
        type=tunnel

Obsrevem nas linhas destacadas em amarelo que os parâmetros left e right fazem referência às pontas da VPN. Para facilitar o processo de cópia do arquivo de configuração nos dois roteadores Linux não faz diferença qual ponta será associada com o parâmetro left ou right, uma vez que o sistema observa as configurações das interfaces de rede para identificar a ponta local. No entanto, é interessante manter as infomações organizadas de forma a utilizar o parâmetro left para fazer referência ao ponto local, enquanto que o parâmetro right fica reservado para o ponto remoto. O leitor interessado em detalhes sobre os demais parâmetros pode obter mais informações na documentação oficial do strongSwan, disponível no link abaixo:

https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

3) Definição da Chave Pré-Compartilhada (PSK)

O segundo arquivo importante de configuração do strongSwan é o /etc/ipsec.secrets, responsável por armazenar a(s) chave(s) pré-compartilhadas que será(ão) utilizada(s) durante o processo de associação dos pares nas fases prévias de estabelecimento da VPN.  Devemos editar esse arquivo em ambos os roteadores com as seguintes configurações para criar uma VPN coerente entre os pares:

###--- Router-Site1: /etc/ipsec.secrets
203.0.113.2 198.51.100.2 : PSK : 'senha13579senha02468'

###--- Router-Site2: /etc/ipsec.secrets
198.51.100.2 203.0.113.2 : PSK : 'senha13579senha02468'

Obs.: Para fins de simplicidade, neste artigo foi utilizada uma chave pré-compartilhada entre os roteadores VPN. No entanto, também é possível a utilização de certificados digitais e chaves privada/pública para adicionar mais segurança ao processo de estabelecimento do túnel. A configuração de uma VPN com uso de certificados/chaves no strongSwan não é complicada, embora demande alguns passos adicionais. Caso haja interesse dos leitores, essa configuração pode ser objeto  de um próximo artigo no blog.

4) Manipulação e Checagem do Serviço da VPN IPSec

Depois de realizadas as configurações anteriores, a VPN IPSec está devidamente configurada para entrar em operação. Para ativá-la basta utilizar o comando ipsec restart e para visualizar seu status basta utilizar os comandos ipsec status ou ipsec statusall, conforme pode ser observado nas saídas trazidas abaixo:

Router-Site1:/# ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.16.0-4-586, i686):
(...) Saída Omitida
Connections:
VPN-Site1-to-Site2:  203.0.113.2...198.51.100.2  IKEv2, dpddelay=30s
VPN-Site1-to-Site2:   local:  [203.0.113.2] uses pre-shared key authentication
VPN-Site1-to-Site2:   remote: [198.51.100.2] uses pre-shared key authentication
VPN-Site1-to-Site2:   child:  192.168.100.0/24 === 192.168.200.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
VPN-Site1-to-Site2[1]: ESTABLISHED 14 seconds ago, 203.0.113.2[203.0.113.2]...198.51.100.2[198.51.100.2]
(...) Saída Omitida
VPN-Site1-to-Site2{1}:  AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
VPN-Site1-to-Site2{1}:   192.168.100.0/24 === 192.168.200.0/24 

O leitor pode constatar que a configuração de uma VPN IPSec no Linux não é tão difícil quanto alguns dizem. Na realidade, possivelmente essa informação seja decorrente da comparação da configuração de uma VPN IPSec com uma VPN TLS através do OpenVPN que é reconhecida por ser mais rápida e simples.

Ainda é importante destacar que caso os roteadores Debian GNU/Linux estejam conectados atrás de um firewall de borda, é importante liberar as portas 500/UDP (utilizada na troca de chaves do ISAKMP) e 4500/UDP (utilizada pelo NAT-T). Além disso, os pacotes IPSec usam dois numéros dedicados de protocolos na camada de rede: 50 (ESP) e 51 (AH).

Por exemplo, supondo que os roteadores estejam atrás de um firewall baseado em iptables, então é necessário aceitar os pacotes nessas portas e traduzir o endereço público de destino (do firewall de borda) para o endereço privado do roteador VPN, de forma que as regras para liberação do tráfego IPSec seriam as seguintes:

iptables -t nat -A PREROUTING -p udp -d <IP_WAN> --dport  500 -j DNAT --to <IP>
iptables -t nat -A PREROUTING -p udp -d <IP_WAN> --dport 4500 -j DNAT --to <IP>

Caso o roteador Debian GNU/Linux seja o próprio firewall, o que é comum em ambientes menores, então é necessário apenas uma regra de entrada para o ISAKMP, já que não ocorre tradução (NAT-T):

iptables -t filter -A INPUT  -p udp --dport 500 -j ACCEPT

Façam seus testes...

Samuel.

Protocolos CDP e LLDP de Descoberta de Vizinhos

Olá Pessoal,

Os protocolos CDP e LLDP são utilizados para comunicação layer-2 entre dispositivos da infraestrutura de uma rede de computadores com a finalidade de descoberta dos vizinhos diretamente conectados. Como ambos os protocolos operam na camada de enlace, os dispositivos sequer precisam ser configurados com um endereço IP para trocarem quadros com informações que permitam sua descoberta na rede de maneira dinâmica. A boa notícia é que ambos os protocolos são extremamente simples de comprender e ainda mais fáceis de configurar! Se você já sabe operar o CDP, então operar o LLDP será tão simples quanto.

O CDP (Cisco Discovery Protocol) é um protocolo proprietário da Cisco e provavelmente um conhecido há anos daqueles que estudam para o exame de certificação CCNA. Outro protocolo que tem exatamente a mesma finalidade é o LLDP (Link-Layer Discovery Protocol) com a diferença de ser um padrão da indústria (IEEE 802.1AB) que pode ser implementado por qualquer fabricante, o que faz dele uma solução bem mais flexível do que o CDP em ambientes com dispositivos de múltiplos fabricantes.  Aqueles que estão estudando para o exame CCNA já devem saber que recentemente o LLDP passou a integrar o componente curricular do novo exame. 

Para praticar os procedimentos de configuração dos protocolos CDP e LLDP o leitor pode construir qualquer cenário com roteadores e switches no simulador Cisco Packet Tracer. Para exemplificar a configuração, irei me basear na simples topologia apresentada abaixo, em que temos um roteador diretamente conectado a outros dois switches que também estão conectados entre si.

Configuração do Cisco Discovery Protocol (CDP)

O CDP já vem habilitado por padrão nas caixas da Cisco, o que é útil para soluções que integram uma infraestrutura totalmente baseada em dispositivos Cisco, por exemplo entre telefones IP e switches Catalyst que se beneficiam da troca de informações da VLAN auxiliar de voz. No entanto, é importante estar atento que são muitas as situações em que é melhor desativar o CDP nas interfaces em que não desejamos que dispositivos vizinhos possam visualizar informações sobre um determinado equipamento, já que a divulgação pode facilitar o processo de descoberta de informações por pessoas não autorizadas. 

É possível desativar globalmente o CDP através do comando destacado em amarelo:

Router(config)# no cdp run
Router(config)# exit
Router# show cdp
% CDP is not enabled

Outra é possível é desativá-lo apenas em alguma(s) interface(s):

Router(config)# interface g0/0
Router(config-if)# no cdp enable

Como o CDP já vem habilitado por padrão, o comando "show cdp neighbors" pode ser utilizado nas caixas para exibir um resumo dos vizinhos diretamente conectados. Esse comando permite identificar qual(is) dispositivo(s) estão diretamente conectados em qual(is) interface(s) do dispositivo local. Caso o administrador queira obter informações mais detalhadas sobre os vizinhos, a palavra detail pode ser adicionada ao comando (show cdp neighbors detail). 

O CDP pode ser bastante útil em ambientes pequenos e médios que não possuem documentação atualizada da sua infraestrutura de redes. A partir de um dispositivo qualquer na infraestrutura é possível identificar os links para seus vizinhos e através do acesso sucessivo aos vizinhos é possível identificar todos os demais vizinhos sob a referência do dispositivo seguinte, de maneira que ao final o administrador terá em mãos a topologia completa da rede.  A propósito, um bom exercício é o leitor utilizar as informações abaixo para desenhar a topologia da rede. 

Observe que a partir do Router é possível identificar que diretamente conectado nele temos o Switch1 e Switch2. Na sequência, a partir do Switch1 podemos confirmar o link anterior para o Router, além de um link adicional para o Switch2. Continuando, no Switch2 podemos confirmar os links para o Router e Switch1. Ao final vocês serão capazes de chegar exatamente na topologia apresentada na figura anterior. Simples assim e bastante útil, não é mesmo?

Router> show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID    Local Intrfce   Holdtme    Capability   Platform    Port ID
Switch1      Gig 0/0          166            S       2960        Gig 0/1
Switch2      Gig 0/1          166            S       2960        Gig 0/1

---

Switch1> show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID    Local Intrfce   Holdtme    Capability   Platform    Port ID
Switch2      Gig 0/2          153            S       2960        Gig 0/2
Router       Gig 0/1          125            R       C2900       Gig 0/0

---

Switch2> show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID    Local Intrfce   Holdtme    Capability   Platform    Port ID
Switch1      Gig 0/2          124            S       2960        Gig 0/2
Router       Gig 0/1          157            R       C2900       Gig 0/1


Configuração do Link-Layer Discovery Protocol (LLDP)

Ao contrário do CDP que vem habilitado por padrão nas caixas da Cisco, o LLDP precisa ser habilitado manualmente pelo administrador antes de interagir com outros equipamentos com o protocolo aberto. Nada de mais nesse ponto, visto que sua ativação global em todas as interfaces é bem simples, conforme pode ser observado no comando destacado em amarelo:

Router# show lldp
% LLDP is not enabled
Router# configure terminal
Router(config)# lldp run
Router(config)# exit
Router# show lldp

Global LLDP Information:
    Status: ACTIVE
    LLDP advertisements are sent every 30 seconds
    LLDP hold time advertised is 120 seconds
    LLDP interface reinitialisation delay is 2 seconds  

Depois de habilitado, o LLDP pode exibir as informações simplificadas dos seus vizinhos exatamente da mesma forma que foi feito anteriormente com o CDP, mudando apenas a palavra CDP por LLDP na linha de comando. A mesma regra vale para exibir informações detalhadas em que basta adicionar a palavra detail no comando de consulta dos vizinhos.  

Router# show lldp neighbors
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID           Local Intf     Hold-time  Capability      Port ID
Switch1             Gig0/0         120        B               Gig0/1
Switch2             Gig0/1         120        B               Gig0/1

Total entries displayed: 2

Router# show lldp neighbors detail
(...) Saída Omitida 

Na realidade o LLDP permite que o administrador possa personalizar sua operação com mais opções do que o CDP. Por exemplo, com LLDP é possível definir quais informações um dispositivo deve ou não deve enviar para seus vizinhos através de atributos de controle, tamanho e valor (TLV). 

Router(config)# lldp tlv-select ?
    mac-phy-cfg           IEEE 802.3 MAC/Phy Configuration/status TLV
    management-address    Management Address TLV
    port-description      Port Description TLV
    port-vlan             Port VLAN ID
    power-management      IEEE 802.3 DTE Power via MDI TLV
    system-capbilities    System Capabilities TLV
    system-description    System Description TLV
    system-name           System NAME TLV 
 

Assim como o CDP, também é possível desativar o LLDP apenas em alguma(s) interface(s) em que não desejamos a troca de informações do dispositvo com seus vizinhos diretamente conectados. Para desativar o protocolo em uma interface específica devem ser utilizados os comandos abaixo:

Router(config)# interface g0/0
Router(config-if)# no lldp receive
Router(config-if)# no lldp transmit

Façam seus testes...

Samuel.

Níveis de Privilégio no Sistema Cisco IOS

Olá Pessoal,

Um conceito básico que todos aprendem logo no primeiro contato com o sistema IOS utilizado em switches e roteadores da Cisco são os níveis de privilégio. A maioria dos profissionais já sabe que por padrão existe o modo de execução (nível 1) em que o usuário somente tem acesso à visualização de alguns comandos básicos sem nenhuma permissão de executar qualquer configuração no dispositivo, além do modo privilegiado (nível 15) que permite a visualização e configuração de todos os recursos do sistema (equivalente ao usuário root no Linux).

Se os níveis padrões são identificados pelos números 1 e 15, é de se esperar que os números intermediários tenham algum significado, não é mesmo? E eles têm, já que o IOS permite a definição de até 16 níveis de privilégio variando de 0 a 15, sendo 0 o mais restritivo e 15 o mais permissivo. Esse detalhe acaba se tornando apenas secundário porque é comum utilizar o comando enable assim que o administrador faz acesso a um dispositivo para obter acesso pleno a todas as configurações, o que torna desnecessário qualquer outro modo intermediário.  

No entanto, em ambientes maiores que possuem muitos equipamentos e diversos técnicos e engenheiros responsáveis pelas configurações das caixas, é natural segregar o pessoal em grupos homogêneos que tenham diferentes privilégios de acesso com o objetivo de restringir a atuação de cada grupo dentro do escopo da sua função. Por exemplo, é prática gerencial bastante comum classificar o pessoal técnico em níveis 1 (entrada), 2 (intermediário) e 3 (avançado), de maneira que os chamados sejam associados com cada nível em função da sua natureza. 

Nesses casos é bastante útil ter a flexibilidade de criar mais níveis de privilégios para esses grupos, ao invés de ficar limitado apenas aos dois níveis padrões 1 e 15, já que o nível 1 tem apenas acesso básico a visualização de poucas configurações e que o nível 15 representa o extremo oposto em que o técnico pode realizar qualquer intervenção na caixa. A ideia dos níveis intermediários é conferir acesso apenas a comandos específicos que um determinado grupo de usuários requer para executar suas funções. Quando criamos um usuário em uma base local que fica armazenada no próprio equipamento switch ou roteador, estamos habituados a fazê-lo da seguinte maneira:

Roteador(config)# line console 0
Roteador(config-line)# login local
Roteador(config-line)# line vty 0 4
Roteador(config-line)# login local

Roteador(config-line)# exit

Roteador(config)# username ADMIN privilege 15 secret SENHA

Utilizamos a configuração "login local" no acesso via console e nas primeiras 5 sessões remotas (vty 0 4) para forçar que seja realizada a autenticação do usuário antes de liberação do acesso, lembrando que o modo padrão (login) consiste apenas em senha sem usuário. O comando destacado em amarelo cria um usuário denominado ADMIN com permissão privilegiada (nível 15), sendo que SENHA é sua senha! A criação de usuários com níveis intermediários de privilégio é tão simples quanto o procedimento anterior, bastando alterar o número do privilégio.

No entanto, de nada adianta alocar um usuário com um nível de privilégio que não teve nenhum comando adicionado pelo administrador naquele nível específico, ou seja, é necessário informar quais comandos ele poderá executar. No exemplo abaixo criaremos um usuário denominado OPERADOR_2 com nível de privilégio 9, de modo que esse usuário será capaz de executar qualquer comando que tenha sido previamente associado pelo administrador com o nível 9 (incluindo os comandos de 0 a 8). Observem nas próximas linhas que a permissão de visualização do arquivo startup-config será restrita apenas aos usuários de nível intermediário 9, ou seja, somente os usuários dos níveis 9 até 15 poderão visualizar todas as configurações que são inicializadas com o equipamento. 

Roteador(config)# username OPERADOR_2 privilege 9 secret SENHA_9

Roteador(config)# privilege exec level 9 show startup-config

Como são várias as possibilidades para personalizar os níveis intermediários, abaixo trago outro exemplo em que é criado o usuário OPERADOR_1 de nível 6. Esse nível permite a configuração simples de endereços IPv4 e IPv6 nas interfaces de rede, inclusive com possibilidade de ativá-las (no shutdown) ou desativá-las (shutdown). Reparem que o segundo termo da sintaxe do comando privilege remete ao modo ou sub-modo de configuração de pertença do comando. Por exemplo, é no sub-modo de configuração de interface (amarelo) onde são configurados os endereços IP e ativadas/desativadas as interfaces.

Roteador(config)# username OPERADOR_1 privilege 6 secret SENHA_6
Roteador(config)# privilege exec level 6 configure terminal
Roteador(config)# privilege configure level 6 interface
Roteador(config)# privilege interface level 6 ip address 
Roteador(config)# privilege interface level 6 ipv6 address
Roteador(config)# privilege interface level 6 no ip address
Roteador(config)# privilege interface level 6 no ipv6 address
Roteador(config)# privilege interface level 6 shutdown
Roteador(config)# privilege interface level 6 no shutdown

Por fim, é importante ter em mente que o usuário pode utilizar o comando "show privilege" para visualizar o nível de privilégio do usuário em que ele está logado no sistema. 

Roteador> show privilege

Current privilege level is 1

Roteador# show privilege

Current privilege level is 15

  

Para que qualquer usuário possa ter permissão para visualizar seu nível de privilégio através do comando anterior, além de ter acesso a todos os demais comandos de visualização do modo padrão de execução (nível 1), podem ser utilizados os seguintes comandos:

Roteador(config)# privilege exec level 1 show privilege
Roteador(config)# privilege exec level 1 show

Como há muitos mais detalhes envolvidos com a configuração dos níveis intermediários de privilégio no sistema IOS, recomendo para aqueles interessados no assunto que façam a leitura da documentação oficial da Cisco no link abaixo:

http://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfpass.html

Façam seus testes...

Samuel.

Configuração de Link P2P em Bridge no Cisco Aironet

Olá Pessoal,

Tradicionalmente os dispositivos Access Point (AP) são utilizados como concentradores em redes sem fio com o propósito de viabilizar uma célula em seu entorno com área de cobertura para que haja comunicação com múltiplos dispositivos clientes de modo ponto-a-multiponto, motivo pelo qual os APs são equipados com antenas omnidirecionais com largura de feixe de 360° no plano horizontal (azimute). Apesar dessa ser a aplicação mais comum, há casos em que é necessário alterar esse comportamento convencional de modo a configurar dois APs em bridge para viabilizar a comunicação ponto-a-ponto, por exemplo na interligação sem fio à distância entre duas unidades remotas de uma empresa (vide figura). 

Nesses casos são acopladas nos APs antenas externas que tenham menor largura de feixe e com maior ganho (dBi) em uma determinada direção. A escolha da antena direcionada mais adequada vai depender da distância entre as duas unidades remotas, destacando que quanto maior o ganho da antena, maior será seu alcance e menor será a largura do feixe no plano horizontal. Por exemplo, antenas parabólicas são as que têm maior ganho (de 20 a 30 dBi) e podem alcançar vários quilômetros de distância (por volta de 50km), dependendo da obstrução no caminho entre as antenas. 

Obs.: Esteja ciente de que antenas parabólicas de alto ganho não devem ser utilizadas sem que o enlace de radiofrequência tenha sido devidamente projetado para irradiar sinal efetivo (EIRP) dentro dos limites legais do seu domínio regulatório, levando em consideração a potência de transmissão, a perda no cabo e demais componentes e o ganho da antena. Conforme Resolução 506/2008 da Anatel, no Brasil o EIRP máximo permitido na frequência de 2,4GHz é de até 30dBm (1000mW) em cidades com até 500.000 habitantes ou de até 26dBm (400mW) em cidades com mais de 500.000 habitantes. Qualquer enlace que esteja operando acima desses parâmetros deve ser licenciado junto à agência. 

O objetivo deste artigo é listar os passos necessários para configurar dois Aironet da Cisco em modo bridge para que seja possível estabelecer um enlace ponto-a-ponto entre duas unidades remotas, com base no cenário apresentado na figura anterior. Repare que as duas unidades pertencem à mesma sub-rede lógica em camada 3 (rede), o que deixa evidente que a conexão em modo bridge nada mais é do que uma ligação em camada 2 (enlace). É como se os APs fossem switches nas unidades remotas que estivessem interligados através de um cabo. Ocorre que na maioria dos casos não é possível fazer a passagem dos  cabos na via pública e a locação de um link dedicado não é barato (quando há disponibilidade no local), então fazer essa ligação através do meio não-guiado (wireless) acaba sendo uma opção atrativa.

Obs.: Também é possível isolar cada unidade em sua respectiva sub-rede lógica (camada 3). Nesse caso, o link ponto-a-ponto entre os dois APs é configurado como sendo uma sub-rede /30 independente das outras duas sub-redes das unidades remotas, de forma que cada AP terá um dos IPs disponíveis na sub-rede /30. O AP de cada unidade remota será diretamente conectado em um roteador de borda, ao invés de um switch. Se essa estratégia for adotada, é importante ter em mente que nos roteadores de borda deverá ser adicionada uma rota para a sub-rede lógica da outra unidade. 

Abaixo o leitor encontra os comandos necessários para configurar ambos os APs através dá interface de linha de comando (CLI) do IOS. Observe que o AP-A foi definido como root bridge e que o AP-B foi definido como non-root bridge, sendo que o canal do enlace é definido apenas no AP raíz. Assim que o link for efetivamente estabelecido, o LED dos Aironet em ambas as unidades mudará sua cor de verde para azul, indicando que os dois APs estão associados entre si. 

AP-A(config)# interface bvi1
AP-A(config-if)# ip address 192.168.0.201 255.255.255.0
AP-A(config-if)# exit
AP-A(config)# ip default-gateway 192.168.0.1
AP-A(config)# dot11 ssid BRIDGE
AP-A(config-ssid)# authentication open
AP-A(config-ssid)# authentication key-management wpa ver 2
AP-A(config-ssid)# wpa-psk ascii PASSWORD
AP-A(config-ssid)# exit
AP-A(config)# interface dot11radio0
AP-A(config-if)# station-role root bridge
AP-A(config-if)# channel 6
AP-A(config-if)# encryption mode ciphers aes-ccm
AP-A(config-if)# ssid BRIDGE
AP-A(config-if)# no shut
AP-A(config-if)# end

---

AP-B(config)# interface bvi1
AP-B(config-if)# ip address 192.168.0.202 255.255.255.0
AP-B(config-if)# exit
AP-B(config)# ip default-gateway 192.168.0.1
AP-B(config)# dot11 ssid BRIDGE
AP-B(config-ssid)# authentication open
AP-B(config-ssid)# authentication key-management wpa ver 2
AP-B(config-ssid)# wpa-psk ascii PASSWORD
AP-B(config-ssid)# exit
AP-B(config)# interface dot11radio0
AP-B(config-if)# station-role non-root bridge
AP-B(config-if)# encryption mode ciphers aes-ccm
AP-B(config-if)# ssid BRIDGE
AP-B(config-if)# no shut
AP-B(config-if)# end

Façam seus testes...

Samuel.

Marcação DSCP e QoS em Roteadores Cisco

Olá Pessoal,

O modelo DiffServ de serviços diferenciados é flexível de acordo com o perfil das aplicações, uma abordagem alinhada com o conceito de nível de serviço (SLA) em que são previamente acordadas as classes de serviços com base em parâmetros como volume de tráfego, disponibilidade e outros que possam assegurar o desempenho adequado dos serviços em execução na infraestrutura de uma rede. O modelo DiffServ é o mais utilizado para implementar QoS porque exige menos dos roteadores do que o modelo IntServ de serviços integrados que requer protocolos inteligentes para que os roteadores possam providenciar a reserva prévia de recursos entre dois pontos (cliente/servidor). 

A RFC 2597 e RFC 2598 descrevem, respectivamente, aquilo que é denominado Assured Forwarding (AF) e Expedited Forwarding (EF), ambos mecanismos de classificação de diferentes níveis de tráfego para serviços diferenciados no modelo DiffServ. Existem quatro classes AF que variam de AF1X até AF4X, sendo que o primeiro número é a prioridade da classe. Quanto maior o número de prioridade, então maior é a importância daquele perfil de tráfego no ambiente. O segundo número (representado por X) varia de 1 a 3 e diz respeito à preferência de descarte dos pacotes, sendo que números maiores têm maior probabilidade de serem descartados. Já a classe EF faz referência ao encaminhamento expresso, ou seja, aquele perfil de tráfego que possui baixa tolerência a qualquer tipo de atraso (tradicionalmente o tráfego de voz). A tabela abaixo traz um resumo de todas as combinações possíveis dos códigos das classes AF e EF.

|-----------------------------------------------------------------|

| Descarte | Classe 1 | Classe 2 | Classe 3 | Classe 4 | Expresso |

|-----------------------------------------------------------------|

| Baixo    |   AF11   |   AF21   |   AF31   |   AF41   |          |

| Médio    |   AF12   |   AF22   |   AF32   |   AF42   |    EF    |

| Alto     |   AF13   |   AF23   |   AF33   |   AF43   |          |

|----------|----------|----------|----------|----------|----------|

O modelo DiffServ propõe um sistema de códigos para classificação de tráfego que é denominado DSCP (DiffServ Code Point) e consiste em sobrescrever os primeiros 6 primeiros bits do campo ToS (Type of Service) do cabeçalho IP, Dessa maneira, cada código diz respeito a uma classe de tráfego que pode receber tratamento diferenciado pelo administrador. A figura abaixo traz um resumo de alguns dos principais códigos DSCP, inclusive com o mapeamento das principais classes AF/EF previamente apresentadas e sugestões de associações com aplicações típicas do cotidiano:

Fonte: Internet (sem especificação de autoria)  

É fato que no primeiro momento parece ser bastante informação teórica para assimilar, então aproveito o cenário simplista da topologia abaixo para exemplificar a configuração prática de alguns desses conceitos, particularmente em relação à marcação de pacotes de uma aplicação qualquer em execução na porta TCP/3050 com o código AF41 (ou DSCP 34) para fins de priorização desse tráfego, além de marcação de um host qualquer com o código AF13 de baixa prioridade.

O objetivo não é discutir cada uma das linhas abaixo com detalhes dos elementos de uma política de QoS, por isso recomendo a leitura do artigo intitulado "Policy-Map na Restrição da Taxa de Tráfego". Apenas vale relembrar que basicamente o processo de configuração de QoS em dispositivos Cisco consiste em três etapas: (i) classificação do tráfego via class-map, (ii) definição da política através de policy-map e (iii) aplicação da policy-map na entrada/saída de alguma interface.

!--- ACL 101 (Referente Tráfego do Host 192.168.0.109 (Host 109)
access-list 101 permit ip host 192.168.0.109 any
access-list 101 permit ip any host 192.168.0.109

!--- ACL 102 (Referente Tráfego do Servidor de Banco de Dados (Firebird)
access-list 102 permit tcp any any eq 3050
access-list 102 permit tcp any eq 3050 any

!--- Classificação do Tráfego da ACL 101 na Class-Map HOST-109
class-map match-all HOST-109
   match access-group 101
   exit

!--- Classificação do Tráfego da ACL 102 na Class-Map FIREBIRD
class-map match-all FIREBIRD
   match access-group 102
   exit

!--- Definição de Políticas na Policy-Map QOS
policy-map QOS
   class HOST-109
      set dscp af13
      police rate 256000 bps
      exit
   class FIREBIRD
      set dscp af41
      end

!--- Aplicação da Policy-Map na Saída da Interface F0/0
interface f0/0
   service-policy output QOS 

Nesse exemplo foram definidas duas class-map, uma vinculada à ACL 101 que faz referência ao host 192.168.0.109 (class-map HOST-109) e outra vinculada à ACL 102 que faz referência à aplicação TCP/3050 (class-map FIREBIRD). Observem que nesse exemplo é realizada apenas a marcação dos pacotes em um roteador isolado, sendo que sua utilização em cenário real também requer a leitura prévia dessa marcação para posterior aplicação de ações/políticas nos demais roteadores intermediários da rede.

Na sequência, a policy-map denominada QOS possui duas políticas, uma relacionada ao host 192.168.0.109 que marca seus pacotes com o código DSCP AF13 (baixa prioridade) e também aplica uma restrição de banda de apenas 256k; e outra relacionada a uma aplicação em execução na porta TCP/3050 que apenas faz a marcação dos seus pacotes com o código DSCP AF41 (alta prioridade) sem aplicar nenhuma outra ação. 

Por fim, o comando "show policy-map" pode ser utilizado para visualizar todas as políticas que foram configuradas em um determinado roteador da rede, lembrando que essas políticas são individuais de cada roteador (distribuídas), ainda que exista um esforço centralizado de definição dessas políticas no ambiente da empresa. Ou seja, é importante estar atento no momento de fazer as configurações das políticas de QoS nos roteadores da infraestrutura porque facilmente a escrita equivocada de regras pode implicar em roteadores contendo políticas contraditórias entre si (ambiguidade).

!---
!--- Visualização de Políticas Previamente Configuradas
!---
R1# show policy-map
  Policy Map QOS
    Class HOST-109
      set dscp af13
      police rate 256000 bps burst 8000 bytes
        conform-action transmit 
        exceed-action drop 
    Class FIREBIRD
      set dscp af41

Façam seus testes...

Samuel.