(Software Defined Everything) Há uns 6 ou 7 anos tivemos o “boom” do SDN – Software Defined Network, quando todos os grandes fabricantes de equipamentos de rede passaram a tentar criar soluções/estratégias que funcionassem de maneira mais simples e ágil, sem estar totalmente amarrado ao hardware. Muita coisa foi feita (ou pelo menos propagandeada) mas pouca coisa funcionou na prática. Naquele momento SDN era a resposta para todas as questões, mas a dificuldade de juntar as peças era enorme. A Cisco, por exemplo, tentou algumas estratégias, que não chegaram a fazer muito sucesso (Converged Access, APIC, SGT,…). Como sempre acontece, a onda passa e fica a espuma. Com menos pressão, e porque não com a experiência acumulada, a Cisco lançou novos equipamentos, reaproveitou alguns produtos, juntou as peças e criou o Software Defined Access (SD-Access). A ideia continua sendo a mesma: simplificar, permitir automação, integração e tornar mais ágil a implementação e operação das redes (neste caseo especificamente das LANs). Cisco SD-Access O conceito é simples (ainda que debaixo do capo as coisas não sejam tão triviais): cria-se um overlay (via software) sobre o underlay (camada física). E como passamos a operar no overlay ganhamos flexibilidade e agilidade. É muito mais fácil segmentar e alterar a rede sem precisar mudar a estrutura física. O SD-Access ainda adiciona inteligência à rede, enquanto melhorar o desempenho e estabilidade. Underlay: É a rede física (switches, roteadores e suas conexões), com configurações que permitem a comunicação entre equipamentos e gerência (DNA-Center). O underlay pode, teoricamente, ter qualquer topologia, mas a recomendação é criarmos uma estrutura baseada em camada 3, usando ISIS como protocolo de roteamento. Inclusive este é o cenário que o DNA-Center cria quando o utilizamos para criar o underlay automaticamente. Overlay: É a rede definida por software, criada sobre o underlay, onde temos a abstração da parte física. É possível inclusive termos várias redes “virtuais” sobre o mesmo underlay. Na camada de overlay o SD-Access utiliza VXLAN (Data Plane) para encapsular e transportar os pacotes IPs pela Fabric. Também é utilizado o LISP – Locator/ID Separation Protocol (Control Plane), para rotear o tráfego VXLAN. Tanto o underlay quanto o overlay podem ser criados/configurados através do DNA-Center (interface gráfica), facilitando o deploy. Componentes do SD-Access O Cisco SD-Access conta com os seguintes componentes: Gerência: A gerência/administração da solução é feita pelo DNA-Center, que permite fazer o design, provisionamento e operação do ambiente. Através do DNA-Center criamos a Fabric, as redes virtuais, bem como as políticas de segurança (segmentação da rede). Temos visibilidade da saúde da rede, ferramentas para troubleshooting, inventário, mapas e topologia. Também podemos instalar outros “APPs”, adicionando funcionalidades a gerência. Ainda temos como item da gerência, o ISE, que integrado ao DNA-Center nos permite fazer a micro segmentação (através de SGT – Scalable Group Tags). No SD-Access temos opção de fazer “macro segmentação” e “micro segmentação”. A macro segmentação é feita com a criação de VNs – Virtuais Networks, que tem plano de dados e plano de controle totalmente separados. Para uma VN falar com outra é necessário um elemento de camada 3, normalmente fora da Fabric, para fazer o roteamento. Já a micro segmentação é feita com a atribuição de SGTs, que podem ser baseadas em IP, nome de usuário ou grupo do AD, tipo de dispositivo, entre outros. E então são criadas regras, onde especificamos quais SGTs podem se comunicar com outras SGTs. Esta parte da solução depende do ISE. Fabric: Fabric são os equipamentos e suas conexões, configurados para formar o underlay e o overlay. Ela é composta por Fabric Control Plane Nodes, Edge Nodes, Intermediate Nodes, e Border Nodes. Fabric Control Plane Node: Elemento (roteador ou switch) responsável por manter o HTDB – Host Tracking Database (usa o LISP para criar e manter esta tabela). Utilizada para mapear a localização dos endpoint. Esta função pode ser desempenhada por um Border Node ou por um equipamento dedicado para isto. Border Node: Equipamento que faz parte da Fabric, e também a comunicação com redes externas (que não fazem parte da Fabric). Preferencialmente usa BGP para anunciar e receber as redes, e faz o mapeamento de redes virtuais (VNs) para VRFs, para manter o tráfego separado também fora da Fabric, se desejado. Podemos ter Internal Border Nodes, que fazem o roteamento para redes externas conhecidas e External Border Nodes, que fazem o roteamento para redes deseconhecidas (gateway of last resort). Edge Node: São os equipamentos equivalentes aos switches da camada de acesso. Nos Edge Nodes conectados os endpoints, e são os Edge Nodes que sinalizam para o Fabric Control Plane Node onde o endpoint está conectado. Também são responsáveis por associar o endpoint a Virtual Network correta, fazer o encapsulamento/desencapsulamento VXLAN e usam o LISP para rotear o tráfego. Intermediate Nodes: Equipamentos entre os Edge Nodes e Border Nodes. Estes elementos fazem apenas o roteamento IP, sem precisar “falar” VXLAN e LISP. Fabric WLC e Fabric APs: Opcionalmente (mas muito comum), a Fabric pode ainda contar com Fabric WLC e Fabric APs. Assim como em uma rede tradicional, a WLC é responsável por gerenciar os APs, mas neste caso a WLC é integrada ao DNA-Center, registrando os MAC Address na tabela de hosts (HTDB) e permitindo a visualização e configuração da rede (cabeada e WiFi) de forma homogênea. Interessante que a WLC normalmente é conectada fisicamente fora da Fabric, em uma camada chamada Shared Services, ou ainda no Data Center. Já os APs, que são conectados aos Edge Nodes, mantem túneis CAPWAP para WLC (controle) e o tráfego dos usuários é encapsulado na respectiva VXLAN, não passando pela controladora. O SD-Access é uma solução nova, disruptiva, e há bastante campo para melhorias, mas o conceito é muito bom. Finalmente teremos visibilidade e segurança na LAN nativamente, e o melhor de tudo, simplificando a administração. Mais informações sobre SD-Access nos links abaixo: Software-Defined Access Design Guide SD-Access Segmentation Design Guide Software Defined Access Under The Hood Até a próxima.
Usando credenciais do AD para logar no ISE
(Ise Ise Baby) O Cisco ISE – Identity Service Engine, é um servidor de políticas e identidade (ou de uma forma simples: um servidor Radius/TACACS bastante inteligente). Ele tem assumido um papel cada vez mais importante na estratégia de segurança da Cisco, integrando com outras soluções, como o Firepower Management Center. Em uma implementação de ISE temos pelo menos um usuário local, com privilégios de Super Admin, para administrar a solução. Porém, também podemos configurar o ISE para fazer a autenticação do acesso administrativo via AD – Active Directory, deixando a solução mais elegante e garantindo que cada administrador tenha suas próprias credenciais. Integrando ISE com AD para acesso administrativo Neste exemplo vamos criar um mapeamento de um grupo específico do AD com o grupo Super Admin do ISE. 1) O primeiro passo é criar no AD um usuário para o ISE. O ISE vai usar este usuário para fazer o join no AD, além de ler os grupos e usuários do domínio. Este usuário precisa ter pelo menos os seguintes privilégios: 2) Depois de instalar o ISE e fazer a configuração inicial (IP, Gateway, DNS, NTP,…), vamos fazer o join no Domínio. Para isso vá em Administration > Identity Management > External Identity Sources > Active Directory. Selecione a opção Add, informe um nome para o Join Point, especifique o domínio e clique Submit. Quando solicitado informe o usuário e senha criado no passo 1 e na sequencia clique em Save. 2.1) Com o sucesso da operação você verá o status como Operacional. 3) Com a integração funcionando, clique na aba Groups e clique em Add > Select Groups From Directory. Selecione os grupos desejados. Clique Ok e Save. 4) Agora vá em Administration > System > Admin Access > Authentication > Password Based e selecione o AD. Clique Save. 5) No menu lateral esquerdo selecione Administrators > Admin Groups e duplique o grupo chamado Super Admin. Dê um novo nome para o grupo, selecione a opção Type External e especifique o grupo de administradores. Clique Save. Note que todos os usuários que fizerem parte deste grupo terão acesso completo ao ISE. 5.1) Confirme que o grupo foi criado e tem um grupo externo associado. 6) Para finalizar, vá em Administration > Permissions > Policy e crie uma nova RBAC Policy, onde vamos dar um nome para a regra, informar o grupo que criamos no passo 5 e o privilégio (Super Admin Menu Access neste caso). Clique Save. 7) Faça o logout e logue com um usuário do AD que faça parte do grupo utilizado. Observe que agora temos a opção de logar com usuário interno e do AD. Neste link temos a referência para configuração do ISE 1.1. Até a próxima.
Pergunte ao Especialista – Umbrella
Que tal saber mais sobre o Cisco Umbrella? Começou dia 16 e vai até o próximo dia 27 o evento “Pergunte ao Especialista – Umbrella, a primeira linha de defesa contra ameaças na Internet”, na comunidade de suporte Cisco. Neste período estarei respondendo as dúvidas que forem postadas. Para participar basta acessar o link este link, fazer o login e deixar uma questão/comentário. Até a próxima.
Cisco Umbrella: Secure Internet Gateway
(Under my umbrella, ella, ella, eh, eh, eh) O Cisco Umbrella tem funcionalidades de um filtro de URL, mas ele tem também outras características que nos permite classificá-lo como um Secure Internet Gateway. Como um filtro de URL tradicional, no Umbrella podemos escolher categorias para liberar/bloquear, e ainda fazer “whitelist” e “blacklist”, informando URLs específicas para permitir ou negar o acesso. No entanto o Umbrella funciona bem diferente de um proxy convencional. Ao invés de trabalhar na camada de aplicação, inspecionando a URL requisitada nos protocolos HTTP e HTTPS (normalmente), o Umbrella trabalha na resolução de nome e por isso consegue ser bem mais eficiente. Além da consulta DNS ser mais simples do que a inspeção de um protocolo, essa é a primeira ação em quase todo acesso à Internet. Ou seja, as ameaças podem ser eliminadas já no primeiro momento. Para utilizarmos o Umbrella precisamos, basicamente, adquirir as licenças, criar uma conta no portal, cadastrar os IPs públicos e então apontar a resolução de nome para os servidores 208.67.222.222 e/ou 208.67.220.220. Depois, basta criar as políticas desejadas, e fazer as integrações necessárias para melhorar a visibilidade e controle dos acessos. Proxy Inteligente Apesar de todos os benefícios da solução baseada em resolução de nome, eventualmente é necessária uma análise mais detalhada para, por exemplo, verificar arquivos transferidos, ou para fazer a inspeção SSL. Nestes casos o Umbrella conta com a funcionalidade Intelligente Proxy, onde o tráfego suspeito é enviado para a nuvem e então é inspecionado com mais atenção. Cisco Talos intelligence, Cisco Web Reputation System, e outros feeds de terceiros são utilizados na inspeção de URL. No caso de arquivos, além da base de reputação, motores antivirus e o Cisco AMP – Advanced Malware Protection, são utilizados para identificar e bloquear arquivos antes deles serem baixados. Mais do que filtro de conteúdo Mas o que realmente é interessante na solução, que é em nuvem, é o foco em segurança e defesa contra ameaças avançadas. Nos últimos anos malwares e ransomwares se popularizaram e estes artefatos, invariavelmente, buscam “a nave mãe”. É muito comum a função “call home”, onde o software malicioso tenta buscar um destino na Internet, para validação, para aguardar as instruções do invasor e, principalmente, para extrair dados. Ao analisar e aprender com os padrões de atividade na Internet, o Umbrella descobre automaticamente infraestruturas preparadas para ameaças atuais e emergentes, bloqueando proativamente as solicitações maliciosas. Infecções por phishing e malware são interrompidas rapidamente, e os dispositivos já infectados são identificados facilmente. Justamente por conta dessas características o Umbrella é uma solução que complementa muito bem outras soluções de segurança, como filtro de conteúdo convencional, NGFW, antivírus… sendo a primeira linha de defesa para usuário que estão dentro ou fora da empresa. Mais informações: Funcionalidades Licenças Documentação Até a próxima.
Fast Ping
(Ping ni mim) Que coisa maravilha é o nosso querido Ping né? Sem dúvida a ferramenta mais comum no dia-a-dia de quem trabalha com redes e TI em geral. Costuma ser a primeira ferramenta que tiramos da manga quando ocorre um problema. Ainda assim, dia desses estava fazendo um troubleshooting usando o Ping a partir da minha máquina Windows, e precisava especificar o timeout além do tamanho do pacote. O Ping aceita essas opções, certo? Mais ou menos… Apesar de ter as opções, o timeout não funciona. Observe que mesmo especificando o timeout em 10 milisegundos (-w 10), as respostas que vieram com mais de 50 ms foram aceitas. Por causa disso fui procurar outro aplicativo, e encontrei o Fping. Depois de baixar o arquivo, basta salvar o executável no local desejado (tem que executá-lo a partir deste local). Agora sim o timeout funciona! O Fping ainda tem outras opções que não encontramos no Ping tradicional do Windows, como permitir pingar vários destinos de uma vez, informar data/horário e salvar o output em um arquivo. Lista de opções do Fping: -t : time between 2 pings in ms up to 1000000 -w : timeout in ms to wait for each reply -c : continuous ping (higher priority than -n) to see statistics and continue – type Control-Break; to stop – type Control-C. -n : number of pings to send to each host -s : amount of data in bytes up to 65500 -S : size sweep: ping with size1, size1 + 1, …, size2 bytes -R : random length between min and max (disabled when using -S) -d : ping with specified data -h : number of hops (TTL: 1 to 128) + print hops -v : Type Of Service (0 to 255) (IPv4-only) -r : record route (1 to 9 routes) (IPv4-only) -f : set Don’t Fragment flag in packet (IPv4-only) -j : print jitter with each reply (only when pinging one host) -g : ping IP range from host1 to host2 (IPv4-only) -H : get hosts from filename (comma delimited, filename with full path) -a : resolve addresses to hostnames -A : print addresses with each reply -p : use a thread pool to ping multiple hosts (enables ICMP dll) x is optional and allows you to choose the number of threads e.g. -p uses a thread for every host -p5 uses a pool of 5 threads/core -i : use ICMP dll instead of raw socket (disables -r) -b : beep on every successful reply (-b- to beep on timeout) -T : print timestamp with each reply -D : print datestamp with each reply -l : limit the output to ping results and errors -o : limit the output to ping statistics -L : logging to a text file Aparentemente a versão para Windows não está mais sendo desenvolvida, mas ainda assim o Fping é um bom utilitário. Até a próxima.
Upgrade Prime Infrasctructure 3.0/3.1 para 3.2
(Prime time) O upgrade do Cisco Prime Infrastructure 3.0/3.1 (versões suportadas abaixo) para a versão 3.2 é um processo manual, via linha de comando. Se você estiver em uma versão inferior as listadas, é necessário primeiro fazer o upgrade para uma versão desta lista. Abaixo o passo-a-passo para fazer o upgrade do Prime Infrasctructure (virtual appliance), sem redundância. 1) Crie um repositório externo. repository FTP_192.168.0.10 url ftp://192.168.0.10 user ftpuser password cisco123 2) Faça o backup da aplicação NCS. BrainPI/admin# backup BKP_22_02_18 repository FTP_192.168.0.10 application NCS DO NOT press ^C while the backup is in progress Aborting backup with a ^C may terminate the backup operation or the backup file may be corrupted Backup Started at : 02/22/18 09:25:21 Stage 1 of 7: Database backup … Database size: 31G — completed at 02/22/18 09:27:00 Stage 2 of 7: Database copy … — completed at 02/22/18 09:27:00 Stage 3 of 7: Backing up support files … — completed at 02/22/18 09:27:16 Stage 4 of 7: Compressing Backup … — completed at 02/22/18 09:27:46 Stage 5 of 7: Building backup file … — completed at 02/22/18 09:30:33 Stage 6 of 7: Encrypting backup file … — completed at 02/22/18 09:31:25 Stage 7 of 7: Transferring backup file … — completed at 02/22/18 09:31:59 % Backup file created is: BKP_22_02_18-180222-0925__VER3.1.0.92.113_BKSZ29G_CPU4_MEM3G_RAM11G_SWAP15G_APP_CK4259071654.tar.gpg Total Backup duration is: 0h:6m:38s BrainPI/admin# BrainPI/admin# show repository FTP_192.168.1.206 BKP_22_02_18-180222-0925__VER3.1.0.92.113_BKSZ29G_CPU4_MEM3G_RAM11G_SWAP15G_APP_CK4259071654.tar.gpg BrainPI/admin# 3) É recomendado instalar um Prime do zero, na mesma versão que esta usando atualmente e restaurar o backup para checar a integridade. 4) Se houver algum backup no repositório default, apague ou mova para um repositório externo. BrainPI/admin# dir disk:/defaultRepo/ Directory of disk:/defaultRepo/ 2588131219 Feb 21 2018 03:36:48 BrainPI-180221-0330__VER3.1.0.92.113_BKSZ29G_CPU4_MEM3G_RAM11G_SWAP15G_APP_CK4238273351.tar.gpg 2622978706 Feb 22 2018 03:36:49 BrainPI-180222-0330__VER3.1.0.92.113_BKSZ29G_CPU4_MEM3G_RAM11G_SWAP15G_APP_CK4273174957.tar.gpg Usage for disk: filesystem 5419024384 bytes total used 83836833792 bytes free 94030061568 bytes available BrainPI/admin# BrainPI/admin# delete disk:/defaultRepo/BrainPI-180221-0330__VER3.1.0.92.113_BKSZ29G_CPU4_MEM3G_RAM11G_SWAP15G_APP_CK4238273351.tar.gpg BrainPI/admin# delete disk:/defaultRepo/BrainPI-180222-0330__VER3.1.0.92.113_BKSZ29G_CPU4_MEM3G_RAM11G_SWAP15G_APP_CK4273174957.tar.gpg BrainPI/admin# BrainPI/admin# dir disk:/defaultRepo/ Directory of disk:/defaultRepo/ Usage for disk: filesystem 202809344 bytes total used 89053048832 bytes free 94030061568 bytes available BrainPI/admin# 5) Copie o arquivo de upgrade (PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz) baixado do site da Cisco para o repositório default. BrainPI/admin# debug transfer BrainPI/admin# debug copy 7 BrainPI/admin# copy ftp://192.168.0.10/PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz disk:/defaultRepo Username: ftpuser Password:********** 6 [12201]: transfer: cars_xfer.c[279] [admin]: ftp copy in of ftp://192.168.1.206/PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz requested 7 [12201]: transfer: cars_xfer_util.c[261] [admin]: ftp get source – ftp://192.168.1.206/PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz 7 [12201]: transfer: cars_xfer_util.c[262] [admin]: ftp get destination – /localdisk/defaultRepo/PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz 7 [12201]: transfer: cars_xfer_util.c[276] [admin]: initializing curl 7 [12201]: transfer: cars_xfer_util.c[289] [admin]: full url is ftp://192.168.1.206/PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz BrainPI/admin# BrainPI/admin# dir disk:/defaultRepo Directory of disk:/defaultRepo 1497 Feb 22 2018 09:36:32 192.168.1.206 4051803537 Feb 22 2018 09:41:13 PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz Usage for disk: filesystem 4258582528 bytes total used 84997275648 bytes free 94030061568 bytes available BrainPI/admin# 6) Pare o serviço NCS. Na versão 3.1 não é obrigatório. BrainPI/admin# ncs stop Stopping Prime Infrastructure… This may take a few minutes… Prime Infrastructure successfully shutdown. Plug and Play Gateway is being shut down….. Please wait!!! Stop of Plug and Play Gateway Completed!! Stopping SAM daemon… Checking for SAM daemon again … SAM Daemon not found… Stopping DA daemon … Checking for DA daemon again … DA Daemon not found… Completed shutdown of all services BrainPI/admin# 7) Agora o upgrade de fato. O COMANDO PRECISA SER EXECUTADO NA CONSOLE! Este passo pode demorar horas. BrainPI/admin# application upgrade PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz defaultRepo Save the current ADE-OS running configuration? (yes/no) [yes] ? Generating configuration… Saved the ADE-OS running configuration to startup successfully Please ensure you have a backup of the system before proceeding. Proceed with the application upgrade ? (yes/no) [yes] ? DO NOT press ^C while the upgrade is in progress Aborting upgrade with a ^C may leave the system in a unrecoverable state Initiating Application Upgrade… Stage 1 of 7: Transferring file … 6 [13913]: transfer: cars_xfer.c[68] [admin]: local copy in of PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz requested 7 [13913]: transfer: cars_xfer_util.c[1197] [admin]: copying /localdisk/defaultRepo/PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz to /storeddata/Installing/.1519303609/PI-Upgrade-3.X_to_3.2.0.0.258.tar.gz …. 8) Verifique o status da aplicação. Os serviços devem estar rodando. BrainPI/admin# ncs status Health Monitor Server is running. ( [Role] Primary [State] HA not Configured ) Database server is running FTP Service is running TFTP Service is running Matlab Server is running Matlab Server Instance 1 is running NMS Server is running. SAM Daemon is running … DA Daemon is running … BrainPI/admin# Mais informações sobre este procedimento podem ser verificadas aqui. Até a próxima.
