O Prime Infrastructure (PI) é a ferramenta de gerenciamento da Cisco para redes wireless e cabeada. Com ele podemos agendar o backup das configurações dos equipamentos, fazer o upgrade de software, verificar quais equipamentos estão consumindo mais recursos (CPU/Memória), ver quais aplicações estão transitando pela rede, centralizar os alarmes, visualizar a área de cobertura dos acess-points, visualizar o status de um determinado usuário (desde que usando 802.1x na rede), gerar relatórios, … entre outras funções. Sem dúvida a possibilidade de olhar para a rede wired e wireless, inclusive verificando o status do usuário, através do mesmo software é um grande atrativo. E o Prime ainda é bonitinho. O que não me agrada completamente é fazer a configuração dos equipamentos (switches, roteadores, controladoras) através do PI. Ele conta com templates prontos, mas caso deseje fazer algo que não esta disponível é necessário criar seu próprio template, o que pode ser um tanto complexo, principalmente se você não tem muito contato com a ferramenta. Por outro lado a utilização de templates é bem flexível, pois podemos trabalhar com variáveis, múltiplas linhas de comandos, situações interativas (que exigiriam a confirmação por parte do usuário), e ainda reutilizar os templates. Veja abaixo como criar um CLI Template para a configuração de atributos (string) SNMP. Este template vai configurar os equipamentos com os comandos snmp-server location e snmp-server contact, deixando duas variáveis para que o usuário preencha as informações na hora do deploy. Criando um CLI Template Neste exemplo estamos considerando que os equipamentos (switches/roteadores) já são gerenciados pelo PI. 1) Abra o Prime é vá em Design > Feature Design. No menu lateral esquerdo escolha CLI Templates > CLI. 1.1) Preencha os campos do painel central (nome do template, descrição, tag), escolha a quais equipamentos ele se aplicará (roteadores, switches). Opcionalmente podemos especificar uma versão de IOS. 2) Na parte de baixo temos o campo CLI Content. Ai inserimos os comandos que deverão ser aplicados nos equipamentos. Neste exemplo teremos uma parte “fixa” e uma parte “variável”. 2.1) Digite o comando snmp-server location (parte fixa, comum a todos os deployments). 2.2) Clique no ícone a direita, quadriculado (Manage Variables). 2.3) Na janela seguinte, clique em Add Row, e crie sua variável. Após preencher os campos clique em Save e depois Add To CLI. 2.4) Com isto criamos a primeira linha de comando que vamos inserir (snmp-server location $Location), sendo que a variável Location será informada pelo usuário no momento do Deploy. 2.5) Digite a secunda linha de comando (snmp-server contact), e insira uma nova variável, como fizemos no item 2.3. 2.6) Salve o template que acabamos de criar clicando em Save as New Template > Save. 3) Agora vamos fazer o Deploy. No Menu lateral esquerdo selecione My Templates > AtributosSNMP, que criamos a pouco. 3.1) Clique em Deploy e selecione os equipamentos que vão ser configurados. Neste exemplo, Routers. 3.2) Preencha os campos Location e Contact, nossas variáveis. 3.3) Clique Apply e Ok. 4) Pronto. A configuração está sendo realizada. Dependendo da quantidade de equipamentos pode demorar alguns minutos. 4.1) Para acompanhar o status do Deploy basta ir no menu superior Administration > Jobs Dashboard. Se tudo der certo você verá o status “Completed” “Success” e os equipamentos estarão configurados. Como sempre, mais informações no nosso amigo User Guide. Até a próxima.
Configurando NTP em roteadores Cisco
A configuração de data e hora é tão simples quanto importante. Tanto que em alguns guias de configuração o NTP é tratado como item de segurança. Percebemos facilmente a importância do horário correto quando estamos analisando mensagens syslog, que trazem a data e horário do evento (veja o post Hora certa nos logs). Que horas o link caiu ? Quando a configuração foi alterada pela última vez? São perguntas do dia a dia e que podemos responder rapidamente se o horário estiver configurado corretamente no equipamento. Todos os roteadores Cisco possuem “software clock”, e alguns possuem “hardware clock”. O software clock roda a partir do momento que o equipamento é ligado, e pode ser configurado com base no hardware clock (se existir), manualmente (comando clock), via NTP ou ainda via VINES Time Services (menos utilizado). Quando o equipamento é reiniciado o software clock perde a configuração, tendo que ser reconfigurado ou re-sincronizado após o boot. Já os equipamentos que contam com o hardware clock tem uma bateria que permite o equipamento manter o horário configurado, mesmo com o roteador sendo desligado, como acontece com os PCs. Também podem ser configurados manualmente (comando calendar), via NTP ou VINES. Ok, sabemos que devemos manter o horário/data configurado corretamente, agora, por que utilizar um serviço de sincronização como o NTP? Como falamos acima, os equipamentos que possuem apenas software clock, após serem reiniciados perdem a configuração, e você precisará acesso-los e reconfigurar o clock. Segundo, que configurando manualmente o horário, haverá diferença entre o horário de um e outro equipamento. Essa diferença, ainda que pequena, causa problemas na hora de fazer correlação de eventos, e também na mudança de “key chain”. OBS: EIGRP pode usar multiplos key chain para autenticação, e cada um ter um tempo de vida diferente. Também podemos usar key chain para gerenciar a troca de chaves de VPNs. O ideal é utilizar um NTP Server da Internet (a.ntp.br, b.ntp.br, são boas opções), mas caso isso não seja possível podemos usar um servidor interno (desde que não seja Microsoft, que implementa NTP de forma diferente….) ou mesmo um roteador. OBS: O serviço de NTP disponível no IOS não permite a conexão direta com “atomic clock”, que é a fonte mais precisa de horário (stratum 0), mas alguns modelos suportam “GPS time source”, que também são stratum 0. Neste caso a conexão é feita através da porta auxiliar. Agora que já temos algumas razões para configurar o horário/data correto nos equipamentos usando NTP, vamos a configuração. NTP Server: NTPServer#conf tNTPServer(config)#clock timezone GMT-3 0NTPServer(config)#ntp master 3NTPServer(config)#endNTPServer#clock set 10:14:00 JAN 27 2015NTPServer# NTP Client: NTPClient#conf tNTPClient(config)#clock timezone GMT-3 0NTPClient(config)#ntp peer 10.123.45.1 prefer normal-syncNTPClient(config)#endNTPClient#clock set 10:14:00 JAN 27 2015NTPClient# Após configurarmos o roteador cliente a sincronização pode demorar alguns minutos. Quanto maior a diferença de horário entre o cliente e o servidor, mais tempo demora a primeira sincronização. Para verificar se NTP está associado utilizamos os comandos “show ntp associations” e “show ntp status”. NTPClient#show ntp associations address ref clock st when poll reach delay offset disp*~10.123.45.1 127.127.7.1 3 14 64 7 103.9 -9.00 3895.4 * master (synced), # master (unsynced), + selected, – candidate, ~ configuredNTPClient#NTPClient#show ntp statusClock is synchronized, stratum 4, reference is 10.123.45.1nominal freq is 250.0000 Hz, actual freq is 250.0019 Hz, precision is 2**24reference time is D871FE42.0CFAC994 (12:08:34.050 GMT-3 Tue Jan 27 2015)clock offset is -9.0003 msec, root delay is 103.90 msecroot dispersion is 3904.40 msec, peer dispersion is 3895.37 msecNTPClient# Observe que no output acima o NTPClient está mostrando que o NTP está sincronizado e é um stratum 4, ou seja, recebeu as informações de clock de um NTP stratum 3 (que foi o configurado anteriormente no NTPServer). ATENÇÃO: Os pacotes NTP possuem um vulnerabilidade e todo equipamento configurado com a versão 3 e anteriores ficam sujeitos a ataques DDoS. Usar autenticação não é uma solução para este problema. Ainda temos outras opções de configuração de NTP e clock, que podem ser verificadas neste link. Até a próxima.
Let´s Encrypt: autoridade certificadora grátis
O Internet Security Research Group (ISRT) junto com Mozilla Corporation, Cisco Systems, Akamai Tech, Electronic Frontier Foundation e IdenTrust, irá disponibilizar a partir do segundo quarto de 2015 uma nova e gratuita certificate authority. A ideia é facilitar e incentivar o uso do TLS (sucessor do SSL) nas comunicações web, melhorando a segurança na Internet. Veja abaixo parte da descrição. Informações pessoais e empresariais fluem através da Internet com mais frequência do que nunca, e nós nem sempre sabemos quando está acontecendo. É claro neste ponto que a criptografia é algo que todos nós deveríamos estar fazendo. Então, por que não podemos usar TLS (o sucessor do SSL) em todos os lugares? Os navegadores em todos os dispositivos suportam. Cada servidor em cada data center suporta. Por que não podemos apenas virar a chave? O desafio é o servidor de certificados. A âncora para qualquer comunicação protegida por TLS é um certificado de chave pública que demonstra que o servidor que você está falando é realmente o servidor que pretendia falar. Para muitos administradores, conseguir um servidor de certificados, mesmo com uma estrutura básica, ainda é trabalhoso. O processo pode ser confuso. Geralmente custa caro. É complicado para instalar corretamente. É uma dor para atualizar. Let´s Encrypt é uma nova autoridade de certificação livre, construída sobre uma base de cooperação e abertura, que permite todos usarem um servidor de certificados para os seus domínios através de um simples clique. Os princípios do Let´s Encrypt são: Grátis: Qualquer pessoa que possua um domínio pode obter um certificado válido, a custo zero. Automático: O processo total de enrollment é feito de maneira simples, durante o processo de instalação ou configuração do servidor, enquanto a renovação ocorre automaticamente em segundo plano. Seguro: Let´s Encrypt servirá como uma plataforma para a implementação de técnicas de segurança modernas e melhores práticas. Transparente: Todos os registros de emissão e revogação de certificados estarão disponíveis para qualquer pessoa que deseje inspecioná-los. Aberto: O protocolo de emissão e de renovação automática será um padrão aberto e todo software possível será open source. Cooperativo: Assim como os próprios protocolos de Internet, Let´s Encrypt é um esforço conjunto para benefício de toda a comunidade, além do controle de qualquer organização. Me parece uma ótima iniciativa. Mais informações no site https://letsencrypt.org. Até a próxima.
Configuração de VPN Remote Access em roteadores Cisco
Segue abaixo o script comentado de configuração para VPN Remote Access em roteadores Cisco. Neste exemplo o usuário remoto deve usar o Client VPN Cisco, e a autenticação é feita localmente no roteador. !— Crie um pool de endereços que serão atribuídos aos clientes ip local pool vpnpool 192.168.1.1 192.168.1.20 !— Crie uma ACL para especificar qual tráfego será traduzido !— (caso o equipamento forneça acesso a internet para os usuários da rede interna) !— Observe que da rede interna para o pool de vpn não haverá tradução (NAT) ip access-list extended ACLNAT deny ip 10.10.10.0 0.0.0.255 192.168.1.0 0.0.0.255 permit ip 10.10.10.0 0.0.0.255 any !— Habilite o NAT (do tipo PAT) para dar “match” na ACL criada e traduzir para o IP da interface conectada a Internet ip nat inside source list 111 interface FastEthernet0/0 overload !— Crie uma segunda ACL que vai definir qual tráfego será criptografado ip access-list extended ACLVPN permit ip 10.10.10.0 0.0.0.255 192.168.1.0 0.0.0.255 !— Habilite a autenticação, autorização e contabilidade (AAA) aaa new-model !— Crie um grupo de autenticação/autorização local para VPN aaa authentication login vpnauthen local aaa authorization network vpnauthor local !— Crie um usuário e senha que será utilizado para autenticação do usuário VPN username user1 password cisco !— Agora a criação da VPN propriamente !— Defina uma politica ISAKMP para a fase 1 crypto isakmp policy 3 encr 3des authentication pre-share group 2 !— Crie um grupo onde temos as definições de DNS/WINS , pre-shared key para autenticação !— Aponte no grupo a ACL criada anteriormente crypto isakmp client configuration group vpnclient key cisco123 dns 8.8.8.8 domain seudominio.local pool vpnpool acl ACLVPN !— Cria as politicas para a fase 2 crypto ipsec transform-set myset esp-3des esp-md5-hmac !— Agora crie um dynamic map e aplique o transform set criado acima crypto dynamic-map dynmap 10 set transform-set myset reverse-route !— Crie um crypto map e aplique o AAA definido anteriormente e o dynamic map crypto map clientmap client authentication list vpnauthen crypto map clientmap isakmp authorization list vpnauthor crypto map clientmap client configuration address respond crypto map clientmap 10 ipsec-isakmp dynamic dynmap ! Associe o crypto map à interface conectada à Internet interface FastEthernet0/0 ip nat outside crypto map clientmap ! Habilite o NAT na interface conectada a rede interna interface FastEthernet0/1 ip nat inside ! Documento da Cisco, em inglês, neste link. Até a próxima.
DHCP Server interno e externo na WLAN Controller
Na WLAN Controller Cisco podemos usar a própria controladora como servidor DHCP ou um servidor externo para entregar endereços IPs para os usuários conectados na rede sem fio. Quando escolhemos usar o DHCP Server interno, devemos criar um pool de endereços na própria WLC, que vai atuar como um servidor DHCP para os usuários conectados aos access-points gerenciados pela referida controladora. Para usar esta opção devemos apontar o IP da interface management como o IP do servidor DHCP. Esta não é uma opção muito utilizada, já que o DHCP interno é um tanto limitado. Recomenda-se usar o DHCP interno apenas em redes com menos que 10 access-points (particularmente recomendo não usar nunca) e é preciso notar que a WLC não preserva o endereçamento entregue após um boot. Ou seja, caso ela entregue um endereço para um usuário e seja reiniciada, ela poderá entregar este mesmo IP para outro usuário, o que geraria conflito. Para configurar o DHCP interno escolha Controller > Internal DHCP Server > DHCP Scope. Clique em New para criar um novo escopo, de um nome e preencha as demais opções (range de IP, máscara de rede, gateway, lease time, servidores de nome). Por fim habilite o escopo (não se esqueça de apontar a WLC como servidor DHCP na interface). Quando escolhemos trabalhar com um servidor DHCP externo, podemos configurar a WLC de duas formas: DHCP Proxy Enable: Esta opção vem habilitada por padrão, e neste caso a WLC atua como um proxy. As requisições de endereço IP chegam dos clientes até a controladora (através dos access-points) como broadcast, no processo normal de requisição de IP via DHCP. A controladora então transforma a requisição em unicast e encaminha para o servidor externo configurado na interface (ou na WLAN). Ao receber a resposta do servidor, a WLC encaminha para o cliente que fez a solicitação. É o mesmo processo que os switches e roteadores fazem quando configuramos o “ip helper-address”. DHCP Proxy Disable (brigde): Neste caso o processo é mais simples. O cliente faz a requisição de IP, via broadcast, e a controladora deixa a requisição passar. Caso um servidor DHCP receba a requisição ele responde com o IP para o cliente. Para configurar o DHCP Proxy, vá em Controller > Advanced > DHCP. Obrigatoriamente precisamos deixar a opção DHCP Proxy habilitada para usar o DHCP Server interno. Além desta configuração global podemos definir a forma de encaminhamento (proxy habilitado ou desabilitado) por interface. Para isso selecione a interface e então DHCP Proxy Mode para mudar o modo de encaminhamento somente para a referida interface. DHCP Override, DHCP Assigment e Opção 82 Além de podermos configurar o IP do servidor DHCP na interface associada a WLAN, também é possível fazer esta configuração na própria WLAN. Isso nos dá flexibilidade, já que podemos sobrescrever a configuração global. Outra opção configurada na WLAN é o DHCP Address Assignment. Quando habilitamos esta opção apenas clientes que receberam IP via DHCP podem conectar na rede. Caso o IP seja configurado manualmente o dispositivo não terá acesso a rede. Por fim o Option 82, que prove segurança adicional quando utilizamos um servidor DHCP externo. Com esta opção habilitada o WLC garante que as requisições são encaminhas para o servidor configurado, evitando que um servidor inválido responda as requisições DHCP. Para utilizar a “opção 82” o DHCP Proxy precisa estar habilitado, e a configuração é feita na interface da WLC. Debugando DHCP na WLC Para verificar o funcionamento e/ou as transações DHCP, via linha de comando, podemos usar os comandos: debug dhcp packet {enable | disable}—Enables or disables debugging of DHCP packets. debug dhcp message {enable | disable}—Enables or disables debugging of DHCP error messages. debug dhcp service-port {enable | disable}—Enables or disables debugging of DHCP packets on the Outras informações no Cisco Wireless LAN Controller Configuration Guide. Até a próxima.
Cisco Netflow: Top Talkers
O protocolo NetFlow é uma parte integrante do software Cisco IOS, que coleta dados sobre o tráfego a medida que ele entra no equipamento. Com ele podemos verificar as aplicações que estão rodando na rede, monitorar usuários, planejar a rede, e ainda usar estas informações para a engenharia de tráfego e análises de segurança. Normalmente utilizamos um coletor, software que recebe os dados Netflow, que mostra graficamente as informações da rede e estatísticas histórica. Mas mesmo sem um coletor, podemos usar o Netflow para nos dar informações importantes. Podemos, por exemplo, visualizar quem são os usuários (IPs) que estão gerando mais tráfego. Uma sessão Netflow traz um conjunto de informações, como IP de origem e destino, porta de origem e destino, e ainda o protocolo. E com isso é possível verificar quem são os “top talkers”. Configurando Netflow Top Talkers em roteadores ISR (IOS) BrainR1(config)#int f0/0BrainR1(config-if)#ip flow ingressBrainR1(config-if)#ip flow egressBrainR1(config-if)#exitBrainR1(config)#ip flow-top-talkersBrainR1(config-flow-top-talkers)#sort-by bytesBrainR1(config-flow-top-talkers)#top 10 Aguarde alguns minutos para que o cache seja preenchido e então use o comando show ip flow top-talkers para verificar os flows. Mais detalhes sobre a configuração de Netflow no Configuration Guide. Top Talkers no Cisco ASR9k No ASR 9000 (IOS-XR) os comandos mudam um pouco, mas também podemos ver os “top talkers”. Configuração no ASR 9k flow monitor-map FLOWMON1 record ipv4 sampler-map SAMPLERMAP1 random 1 out-of 50 Int Giga0/0/0/0flow ipv4 monitor FLOWMON1 sampler SAMPLERMAP1 ingress Para verificar os Top Talkersshow flow monitor FLOWMON1 cache sort counters bytes top location 0/0/CPU0 Mais detalhes da configuração de Netflow no ASR 9000 neste link. Até a próxima.
