Quem pretende fazer o LAB para o CCIE Voice atenção! A partir da segunda quinzena de julho de 2009 estará em vigor a versão 3 do LAB. A nova versão cobre os seguintes tópicos: 1.00 Implement and Troubleshoot Campus Infrastructure and Services 1.01 VLAN 1.02 DHCP 1.03 TFTP 1.04 NTP 2.00 Implement and Troubleshoot CUCM Endpoints 2.01 CUCM SCCP Endpoints 2.02 CUCM SIP Endpoints 3.00 Implement and Troubleshoot CUCME Endpoints 3.01 CUCME SCCP Endpoints 3.02 CUCME SIP Endpoints 4.00 Implement and Troubleshoot Voice Gateways 4.01 T1/E1 PRI 4.02 T1/E1 CAS 4.03 H.323 4.04 MGCP 4.05 SIP 4.06 H.323 RAS 4.07 IP-IP Gateway/CUBE 5.00 Implement and Troubleshoot Call Routing Policies 5.01 Route Patterns and Dial-peers 5.02 Digit Manipulations and Translations 5.03 Class of Services 5.04 Route Selection Preference and Redundancy 5.05 Mobility and Single Number Reach 6.00 Implement and Troubleshoot High Availability Features 6.01 SRST 6.02 AAR 7.00 Implement and Troubleshoot Media Resources 7.01 CODEC Selection and Flexibility 7.02 Conference Bridges 7.03 Transcoder 7.04 Music-on-hold 7.05 Media Resources Preference and Redundancy 7.06 Other CUCM Media Resources 8.00 Implement and Troubleshoot Supplementary Services 8.01 Call Park 8.02 Call Pickup 8.03 Barge 8.04 Callback 8.05 Other Supplementary Services 9.00 Implement and Troubleshoot Other CUCM Voice Applications 9.01 Extension Mobility 9.02 IPMA 9.03 Other CUCM Voice Applications 10.00 Implement and Troubleshoot QoS and CAC 10.01 L2/L3 Traffic Classifications and Policing 10.02 L2/L3 Queuing Mechanisms 10.03 L2 LFI 10.04 RSVP 10.05 Call Admission Control 11.00 Implement and Troubleshoot Messaging 11.01 Cisco Unity Connection 11.02 Cisco Unity Express 11.03 Call Handling and Routing 12.00 Implement and Troubleshoot Cisco Unified Contact Center Express 12.01 Advanced Configuration 12.02 Script Customization 12.03 Redundancy 13.00 Implement and Troubleshoot Cisco Unified Presence 13.01 CUCM Presence 13.02 Cisco Unified Presence Server Integration O exame prático, que tem 8 horas para ser realizado, custa $ 1.400,00 e pode ser realizado apenas nas seguintes localidades: Brussels (Belgium), RTP e San Jose (USA) Sydney (Austrália) e Tokyo (Japan). Até a próxima. Fonte: The Cisco Learning Network
CCIE Wireless
Após permitir a realização da prova CCIE Wireless Beta (prova escrita), agora é anunciada a prova definitiva. A partir de 17 de fevereiro de 2009 os candidatos poderão realizar a prova teórica (CCIE Wireless 350-050) nos centros VUE, como as demais provas. O LAB (prova prática) estará disponível a partir de abril de 2009, e poderá ser realizado em Brussels (Bélgica), San Jose (EUA) e Sydney (Austrália). A prova teórica conta com 100 questões de múltipla escolha, e deve ser realizada em até 2 horas. O treinamento indicado, conteúdo programático e materiais de apoio podem ser encontrados aqui. Já o LAB conta com 8 horas de duração e custa $ 1.400,00. Mais informações sobre o LAB podem ser verificadas aqui. Para finalizar, ainda em 2009 a Cisco vai lançar uma certificação Wireless a nível “Professional” (CCWP ???). Aguardemos. Até a próxima.
Salve a configuração de forma segura
A partir da versão 12.3(8)T do Cisco IOS, foi inserida a feature Resilient Configuration. Esta feature permite salvar uma cópia da runnging-config de forma segura na memória do roteador (não é possível deletar esta cópia via CLI). Assim, quando ocorrer um problema pode-se rapidamente restaurar a configuração. Habilitando o Resilient Configuration: BrainworkRT01# conf t BrainworkRT01(config)#secure boot-config BrainworkRT01(config)# Com o comando acima (secure boot-config) uma cópia da running-config é armazenada na memória do roteador, mas não aparece no quando o usuário digita dir. Verificando a cópia secura: BrainworkRT01#show secure bootset IOS resilience router id FTX0827B1Y3 IOS image resilience is not active IOS configuration resilience version 12.4 activated at 13:17:26 UTC Mon Dec 1 2008 Secure archive flash:.runcfg-20081201-131726.ar type is config configuration archive size 4989 bytes O arquivo de nome runcfg-20081201-131726.ar foi criado. Restaurando a cópia da running-config: BrainworkRT01(config)#secure boot-config restore filename ios resilience:configuration successfully restored as filename Para restaurar a cópia utilize o comando secure boot-config restore filename (nome que o arquivo receberá). Para cancelar o secure boot-config é preciso estar na console do equipamento: BrainworkRT01(config)#no secure boot-config BrainworkRT01(config)# *Dec 1 13:23:19.778: %IOS_RESILIENCE-5-CONFIG_RESIL_INACTIVE: Disabled secure config archival [removed flash:.runcfg-20081201-131726.ar] Além da running-config também é possível fazer uma cópia secura do IOS. Limitações e outras informações sobre Resilient Configuration podem ser verificadas aqui. Até a próxima.
Editando ACL numerada
Access-lists são com certeza umas das features mais utilizadas nos roteadores. Servem para bloquear/liberar tráfego que passa pelo roteador, escolher as redes que passarão por NAT, que tráfego será criptografado em uma VPN, quais rotas serão distribuídas por um determinado protocolo de roteamento e podem ainda ser utilizadas em uma infinidade de situações. Podemos dividir as ACLs em dois tipos: Numeradas e Nomeadas. Até algum tempo atrás as ACLs nomeadas tinham uma grande vantagem em relação as ACLs numeradas, pois com elas era possível editar uma linha da ACL sem a necessidade de deletar toda a access-list. Enquanto que para editar um ACL numerada você tinha que deletar toda a ACL, editar no bloco de notas e colocar novamente no roteador. Mas a partir da versão 12.3 do IOS é possível editar uma ACL numerada da mesma forma que uma ACL nomeada. Para isso foi adicionado ao software a função de adicionar um número de seqüencia para cada linha de uma ACL, seja ela numerada ou nomeada. Assim é possível excluir, alterar ou incluir novas linhas a ACL. Exemplo: ! A ACL pode ser criada normalmente ou via IP Access-list Brainwork01#conf t Brainwork01(config)#access-list 100 permit tcp 10.10.1.0 0.0.0.255 any Brainwork01(config)#access-list 100 permit tcp 10.10.2.0 0.0.0.255 any Brainwork01(config)#access-list 100 permit tcp 10.10.3.0 0.0.0.255 any Brainwork01(config)#access-list 100 permit tcp 10.10.4.0 0.0.0.255 any Brainwork01(config)#exit ! Observe que cada linha da ACL tem um identificador Brainwork01#sh access-lists Extended IP access list 100 10 permit tcp 10.10.1.0 0.0.0.255 any 20 permit tcp 10.10.2.0 0.0.0.255 any 30 permit tcp 10.10.3.0 0.0.0.255 any 40 permit tcp 10.10.4.0 0.0.0.255 any ! Para adicionar uma nova entrada à ACL existente, basta tratá-la como uma ACL nomeada ! Por exemplo, vamos colocar uma nova regra, entre a entrada 10 e 20 Brainwork01#conf t Brainwork01(config)#ip access-list extended 100 Brainwork01(config-ext-nacl)#15 permit udp 10.10.1.0 0.0.0.255 172.16.0.0 0.0.0.255 Brainwork01(config-ext-nacl)#end ! Pronto, a nova linha foi adicionada onde queríamos Brainwork01#sh access-list Extended IP access list 100 10 permit tcp 10.10.1.0 0.0.0.255 any 15 permit udp 10.10.1.0 0.0.0.255 172.16.0.0 0.0.0.255 20 permit tcp 10.10.2.0 0.0.0.255 any 30 permit tcp 10.10.3.0 0.0.0.255 any 40 permit tcp 10.10.4.0 0.0.0.255 any ! Para excluir uma entrada pontualmente, basta entrar no modo de edição ! e apontar o identificador da linha a ser excluída (30 no exemplo abaixo) Brainwork01#conf t Brainwork01(config)#ip access-list extended 100 Brainwork01(config-ext-nacl)#no 30 Brainwork01(config-ext-nacl)#end ! Mais uma vez a ACL 100 foi editada, sem a necessidade de ser excluída Brainwork01#sh access-lists Extended IP access list 100 10 permit tcp 10.10.1.0 0.0.0.255 any 15 permit udp 10.10.1.0 0.0.0.255 172.16.0.0 0.0.0.255 20 permit tcp 10.10.2.0 0.0.0.255 any 40 permit tcp 10.10.4.0 0.0.0.255 any Brainwork01# Caso uma nova entrada seja adicionada, sem que o número de seqüencia seja informado, ela será automaticamente inserida no fim da ACL. Até a próxima.
SSH2 em switches Cisco
O SSH (Secure Shell) é um protocolo desenvolvido como alternativa ao Telnet e outros utilitários de conexão remota conhecidos como Berkeley R Utilities (rlogin, rsh, rcp e rdist), todos considerados métodos de acesso remoto não seguro. O SSH cria um canal criptografado entre o client e server, permitindo comunicação segura, mesmo em um meio inseguro (como a Internet, por exemplo). Para isso o SSH faz a autenticação do usuário e cria uma chave para a sessão. Quando o client conecta pela primeira vez a um determinado server (servidor linux, roteador ou switch, entre outros) o SSH cria uma chave que será o “fingerprint” para aquele server e pergunta se você deseja aceitá-la. Esta chave fica armazenada na base de dados local do client. Atualmente temos duas versões do SSH: SSH1 e SSH2. O SSH2 conta com várias vantagens em relação a versão anterior, onde podemos destacar a maior segurança e velocidade para criptografia, e suporte a diferentes tipos de algoritmos de chaves públicas. Para ativar o SSHv2 em switches Cisco, basta seguir o exemplo abaixo: BrainworkSW01#conf t BrainworkSW01(config)#ip domain-name brainwork.com.br BrainworkSW01(config)#crypto key generate rsa modulus 1024 The name for the keys will be: BrainworkSW01.brainwork.com.br % The key modulus size is 1024 bits Generating RSA keys … [OK] BrainworkSW01(config)#ip ssh time-out 60 BrainworkSW01(config)#ip ssh version 2 BrainworkSW01(config)#ip ssh authentication-retries 3 BrainworkSW01(config)#line vty 0 15 BrainworkSW01(config-line)#transport input ssh BrainworkSW01(config-line)#end BrainworkSW01#wr Para excluir a chave criada: BrainworkSW01#conf t BrainworkSW01(config)#crypto key zeroize rsa % Keys to be removed are BrainworkSW01.brainwork.com.br. Do you really want to remove these keys? [yes/no]: yes BrainworkSW01# Os seguintes switches não suportam SSH: Catalyst 1900, 2900 XL, 3500 XL, 2800, 2948G-L3, 4840G-L3 and 4908G-L3. Até a próxima.
Evitando o IP Spoofing
IP Spoofing é uma técnica que consiste em mascarar o IP de origem real por um outro IP e é um dos primeiros passos para uma série de ataques como man-in-the-middle, routing redirect, blind spoofing e SYN flood, entre outros. Para prevenir o spoofing, e consequentemente evitar ataques, de fora da rede, é necessário criar uma access-list no roteador que está conectado a Internet (Ingress Filtering). Inclusive existem algumas RFCs que tratam do assunto, em especial RFC 3330 (endereçamento de uso específico), RFC 1918 (endereçamento privado) e RFC 2827 (Filtro de entrada na rede) Basicamente como “melhores práticas” temos que nunca um IP privado, de uso específico ou seu próprio IP, deve ser aceito como tráfego inbound na interface outside de um roteador conectado a Internet. Assim, tendo como exemplo a topologia abaixo, a ACL anti-spoofing (Ingress Filtering) deve ser aplicada na interface s0/0 no sentido inbound. ACL anti-spoofing para o cenário acima: RT01#conf t RT01(config)#! RFC 3330 RT01(config)#access-list 110 deny ip host 0.0.0.0 any RT01(config)#access-list 110 deny ip 127.0.0.0 0.255.255.255 any RT01(config)#access-list 110 deny ip 192.0.2.0 0.0.0.255 any RT01(config)#access-list 110 deny ip 224.0.0.0 31.255.255.255 any RT01(config)#! RFC 1918 RT01(config)#access-list 110 deny ip 10.0.0.0 0.255.255.255 any RT01(config)#access-list 110 deny ip 172.16.0.0 0.15.255.255 any RT01(config)#access-list 110 deny ip 192.168.0.0 0.0.255.255 any RT01(config)#! Seu próprio IP público RT01(config)#access-list 110 deny ip 200.1.1.1 0.0.0.15 any RT01(config)#! Permite os demais IPs RT01(config)#access-list 110 permit ip any any RT01(config)#int s0/0 RtBrainwork01(config-if)#! aplique a ACL no sentido inbound RtBrainwork01(config-if)#ip access-group 110 in RtBrainwork01(config-if)#end RT01#wr Ainda no combate ao spoofing é indicado que seja criada uma ACL para a interface inside do roteador, também no sentido inbound. Essa ACL, conhecida como Egress Filtering, deve permitir que apenas os pacotes com IP de origem da rede interna passem pelo roteador. Até a próxima.
