Redes on Cisco Redes

BLOG – Cisco Meraki – Radius em Cloud

Thu, 31 Mar 2022 00:00:00 +0000

Olá Pessoal,

Já faz um tempo que não escrevo aqui para vocês, entretanto acabei ficando sumido devido a outras características e obviamente não podemos negar que nosso tempo fica cada vez mais escasso.

Enfim, não é lugar para “muro de lamentações” o importante que sempre estamos por aqui e tentando apresentar novos conteúdos para vocês e alguns produtos que vocês podem utilizar/pesquisar para ajudar no entendimento maior do seu dia-a-dia.

Radius no Meraki

Como todos sabem hoje cada vez mais, estamos procurando formas de amenizar os impactos relacionados a segurança, e claro não podemos esquecer de utilizar o protocolo 802.1x para garantir o acesso seguro de seus usuários ao ambiente de WI-FI.

Desta forma, fiz alguns testes para habilitar o Radius no Meraki fazendo com ele pudesse especificamente em um SSID, fazer autenticação através de Radius + 802.1x.

Entretanto, estava procurando algo em cloud free que eu pudesse testar e não precisasse trabalhar localmente com algum free radius. Hoje sabemos que temos o free-radius, que acredito que ainda vou escrever sobre ele em nosso BLOG, entretanto fui em algo talvez mais rápido para testar os recursos.

Configuração no Meraki

Para esses recursos temos parâmetros rápidos e práticos que podem ser visualizados conforme abaixo:

Baseado na figura acima, precisamos garantir que estamos configurando no modo “Enterprise”, porém com a definição de seu Radius Server.

Após configurar no drop-down, podemos observar as configurações adicionais que necessitam ser executadas, para que eu possa autenticar em um servidor Radius. Vale ressaltar, que devido ao ambiente Meraki ser em Cloud, as definições podem também serem executadas em seu ambiente on-prem, porém o acesso ao servidor precisa ser liberado para que a Cloud Meraki possa alcançar esse servidor.

As configurações de EAP+EAPOL foram mantidas em modo “default”, pois são ambientes de testes, entretanto caso necessite executar no ambiente de produção você pode adequar as suas necessidade do ambiente de produção.

Os endereços adquiridos da JumpCloud pode ser visualizados através dessa documentação.

OBS.: Existe uma limitação via JumpCloud que a porta Radius 1813(accounting) não é suportado.

Configuração no JumpCloud

Para quem deseja conhecer um pouco do portfolio da JumpCloud recomendo acessar o site deles e visualizar as possibilidades de atendimento.

Eu acabei encontrando por acaso, pesquisando sobre opções de integração com o Meraki, na qual achei bastante documentação para fazer não somente o uso de Radius mas de outras facilidades, ainda como sendo um plano free. Futuramente, vou trazer alguns conceitos de SSO(Single Sign On) entre as plataformas.

Para configurar o Radius, basicamente precisamos obter o IP Público, executar o “match” da senha que será adicionada em ambas plataformas.

Conforme pode ser visualizado acima, temos a opção de utilização de MFA, porém na característica de autenticação do WIFI pelos documentos não é recomendado e poderia ser um caso em utilizar essa autenticação para uma característica de VPN.

Após esses passos devemos cadastrar os usuários na plataforma(10 são free), ou seja, será através desse “user” que você deverá utilizar quando solicitado o “join” para o SSID escolhido.

OBS.: Pode observar que para esse usuário eu criei um MFA para eu logar no portal Jumpcloud, caso em futuros testes(VPN, SSO) eu possa utilizar ele para adicionar mais uma camada de segurança.

Talvez vocês já devem estar pensando em uma situação onde tenho IP dinâmico que fica atrelado ao acesso para o ambiente que esta nosso AP, ou seja, vou ficar trocando o IP? Sim. Porém, existe uma forma de fazer atualização deles via API :). Caso, tenham interesse avise nos comentário, pois posteriormente executo um post explicado como fiz esse processo.

Autenticação no WI-FI

Para executar autenticação podemos observar que nesse momento é solicitado “user+pwd”, ou seja, não estamos mais no modo PSK. 🙂

Após autorização será notificado sobre o certificado, pois devido a estarmos utilizando EAP-TTLS/PAP ou EAP-PEAP e deveremos usar essa autenticação para garantir maior segurança nos dados transmitidos entre as pontas (Meraki+JumpCloud).

Conforme abaixo será apresentado o certificado para que você confirme a autenticação, bem como garantir a validade do certificado.

Vale lembrar que você também poderia fazer o download desse certificado e fazer a instalação do mesmo em seu ambiente para garantir que não tenha essa validação ao seu usuário. Você pode obter mais informações sobre o certificado.

Logs

Após todo o processo de configuração e autenticação sempre é interessante avaliarmos os logs capturados nas plataformas, para verificar se de fato como poderemos fazer um futuro “troubleshooting” e consequentemente observar se funcionou da forma que deveria. 🙂

Logo abaixo, podemos observar log sendo exposto pela ferramenta JumpCloud que pode ser visualizada através do menu Insight->Directory. Desta forma, vimos que autenticação foi executada utilizando serviço de Radius com os parâmetros EAP-PEAP via usuário especifico.

Após isso podemos observar ao mesmo tempo essa notificação no portal Meraki, onde conseguimos observar EAP e a característica de sucesso do usuário sendo autenticado via 802.1x. Temos ainda uma possibilidade de fazer um “check” ao servidor radius através do portal Meraki, para assim garantirmos e identificarmos como está o tempo de resposta até o seu servidor na Cloud(JumpCloud)

Posteriormente podemos ainda consolidar através do menu “Clients” e avaliar como está sendo feita associação desse usuário e ao mesmo tempo garantir qual “user” foi autenticado, bem como garantir associação via 802.1x.

Conclusão

Observando a facilidade de efetuar as configurações em ambas as plataformas, na minha visão faz todo sentido termos algo de Radius como serviço em Cloud, ainda mais quando temos ambas as soluções sendo gerenciadas em cloud. Obviamente, ainda existe muita coisa que acaba acontecendo nos “bastidores” e que com certeza iremos analisar posteriormente, principalmente nas características de segurança observando na perspectiva de como esse usuário e hash estão sendo encaminhado entre as pontas.

Entretanto, vale ressaltar que baseado no protocolo 802.1x já podemos ter a garantia de algumas metodologias de segurança para garantir essa autenticidade, bem como evitar alguns “eavesdropping” localmente.

O que vocês acharam desses parâmetros? Desejam observar mais algum detalhe sobre o que foi apresentado? Deixe seus comentários.

Abs,
Rodrigo

BLOG – Podcast Cisco Champion – Small Business – Big Value

Mon, 19 Jul 2021 00:00:00 +0000

Olá Pessoal,

Como vocês devem ter percebido estou publicando mais esses posts relacionado ao podcast do Cisco Champion, na qual são episódios que estou participando.

Neste episódio foi conversado sobre o mercado em grande expansão que é a relação do “Small Business”, consequentemente devido ao fatores que vocês devem imaginar (WFH, pandemia, etc), porém também relacionado a essa médias e pequenas empresas que estão crescendo exponencialmente e as soluções principalmente de segurança e colaboração são torres de tecnologia essenciais para esses pilares no crescimento e expansão do negócio.

Confira abaixo o episódio:

Caso tenha mais interesse, podem pesquisar também no site da Cisco sobre esse portfolio Small Business. Deixe seu comentário abaixo, mencionando se as abordagens feitas durante o podcast estão dentro das expectativas sobre a tecnologia.

Abs,

Rodrigo

BLOG – O que é ping? Protocolo ICMP?

Mon, 05 Apr 2021 00:00:00 +0000

Olá Pessoal,

Após ter feito uma pequena pesquisa que acabei colocando no Twitter de nosso BLOG, para qual estava querendo obter informações sobre quais tópicos vocês mais gostariam de visualizar, e por minha surpresa o que acabou tendo mais votos, conforme abaixo:

Qual tópico você gostaria de visualizar em nosso BLOG?

Caso não esteja nas opções deixe nos comentários.#CiscoChampion #networkengineer #automation #cloudsecurity #shareknowledge #vExpert

— Blog CiscoRedes (aka @rar_21) 🇧🇷 (@BlogCiscoRedes) February 28, 2021

Desta forma, e como solicitado vou tentar trazer alguns posts explicando um pouco desses conceitos básicos.

Para essa primeira abordagem, eu resolvi trazer um ítem que acredito que muitos usam independentemente de sua área de atuação ( Rede, Infra, Telecom, Cloud, Programação, etc ), pois em algum momento você já executou um teste de ping em seu prompt.

O que é o ping?

É uma ferramenta de diagnóstico que testa a conectividade entre dois nós ou dispositivos em uma rede. Com isso, podemos garantir que os dois pontos ( origem e destino ) são alcançavéis, ou seja, podem se comunicar.

Isso pode ser pensado de forma mais abragente, ou seja, alcançar pontos remotos mesmo que estejam dentro de seu ambiente de trabalho ( LAN ), como também ambientes que estão na Internet ( WAN ).

Qual protocolo é utilizado?

Como já estamos colocando o termo ” Ping “, e devido a ser o mais conhecido, podemos parar e pensar para avaliar qual protocolo ele está usando?

Sim, e de fato temos a menção para o ICMP ( Internet Control Message Protocol ), para qual também podemos consultar via RFC792.

O ICMP é uma aplicação?

Muitas das vezes o pessoal pergunta se o ICMP é uma aplicação.

Podemos observar neste exemplo que capturei através do Wireshark, que o ICMP no debug ele não está diretamente atrelado a camada de aplicação, mas ele é considerado como um artefato da camada de Rede, ou seja, olhando na visão do modelo OSI, temos a consideração que está na camada de Rede.

Mas vale lembrar que o ICMP não tem a necessidade de obter recursos da camanda de transporte ( TCP ou UDP ), portanto ele é considerado como ” connectionless ” fazendo com que não há necessidade de abrir conexão para enviar a mensagem.

O ping é uma aplicação?

Neste questionamento temos uma resposta mais afirmativa que de fato aplicação acaba sendo mais definida pela terminologia, ou seja, a menção do ” ping “.

Como todos sabem hoje temos algumas ferramentas que devido algumas caracteristicas estão em ” background ” executando essa função, e que também podem ser ouvidas como ” ping sweep “. As ferramentas que eu poderia mencionar seria:

- - Solarwinds PingSweep
  - Pingdom
  - Site24x7
  - Grafana Cloud
  - PRTG Network Monitor

Mensagens ICMP

Como observamos anteriormente o protocolo utilizado para nosso conhecido ping é o ICMP, mas dentro desse cabeçalho temos diversas mensagens que podem trazer validações e entendimento do que de fato pode estar ocorrendo entre esses pontos remotos ou locais.

Como já definido na RFC temos a seguintes menção:

Com este cabeçalho os campos que mais observamos seria o ” Type ” e o ” Code “, pois são através dessas flags que iremos obter os valores correspondentes a cada ação que estão ocorrendo dentro desse percurso entre origem e destino. Sempre observo através da documentação do IANA referente esses dados, pois acredito que fica fácil para pesquisar e observar as mensagens.

Tradicionalmente os ” Types ” 0, 3, e 8 que acabamos mais visualizando no dia a dia, pois no 3 iremos ter diferentes ” Codes ” que vão nos dar visibilidade sobre a menção de ” Destination Unreachable “. Nele podemos observar sobre caracteristicas de ” host unreachable “, ” Fragmentation Needed “, etc. Vale muito a pena interpretar esses código diretamente através de um sniffer.

Como dica, faça alguns testes usando seu próprio prompt e tente identificar esses parâmetros.

ICMPv6 – Julga-se para o IPv6

Todos devem estar se perguntando sobre o porque o ICMPv6. Será que vou utilizar?

Eu resolvi mencionar, pois de fato ele é muito importante quando falamos nova estrutura para utilização do IPv6, justamente porque ele é encarregado de fazer o trabalho que anteriormente era feito por outros protocolos no IPv4. Os protocolos que estão atrelados junto com o ICMPv6 seria o ARP, RARP, IGMP, bem como também temos a menção do MLD ( Multicast Listener Discovery ), NDP, autoconfiguração de endereçamento IP no processo ” Stateless “

Você pode visualizar com mais detalhes através desse link. Vale ressaltar também que temos itens importante quando mencionamos sobre descoberta de vizinhos por esse protocolo, que por sua vez teremos o Router Solicitation ( RS ), Router Advertisement ( RA ), etc.

Caso queiram mais detalhes sobre essa funcionalidade deixe um comentário que posso preparar um conteúdo para todos.

Resumo

De fato pessoal, esse tema é muito falado em nosso dia a dia, e foi nesta forma que pensei em trazer esse formato de questionamentos para tentar explicar um pouco do que escuto em algumas aulas e também para verificar se faz sentido isso que acabei de expressar para vocês.

O que vocês acharam? Estão de acordo? Consegui abordar de fato um tema basico de redes?

Abs,

Rodrigo

Resumo do BLOG – Referência 2020

Sun, 03 Jan 2021 00:00:00 +0000

Olá Pessoal,

Gostaria de compartilhar um pouco sobre nossa trajetória de 2020, um pouco atrasado, pois já estamos em 2021 ( rs ), porém devido a um outro projeto que logo mais vocês irão descobrir, eu acabei atrasando um pouco com as informações, mas volto aqui para trazer alguns números e avaliar o que conseguimos ajudar a comunidade, bem como também conforme a promessa em nosso post executado em 2019, declarando um pouco sobre os temas que iria tentar abordar.

Todos sabem que esse ano foi complicado para todos, mas conforme demonstração de nossos números abaixo, posso dizer como sendo um blog que trata de assuntos específicos e sendo com um hobby adicional, eu declaro que os números estão ótimos ( rs!! ).

Logo abaixo, podemos ver os posts mais visitados, e diga de passagem é um tópico que foi abordado em 2016.

Nesta linha de raciocíonio, eu consegui postar um total de 32 posts ( contando este que seria de 2020..rs!), ou seja, seria 1,5 post por semana, que de alguma forma eu acho um valor expressivo.

Re-avaliando aquilo que havia pensado em 2019, eu até consegui fazer as tratativas, pois eu consegui trazer mais conteúdos técnicos explicando sobre a tecnologia Meraki ( Insight, Umbrella+MR, SDWAN ), Gerência via IPFabric, Segurança WIFI, adicionei mais alguns códigos em minha conta do GitHub, etc

Conquistas

Neste ano de 2020 eu continuei dentro dos 3 programas de comunidades que venho tocando ( Cisco Champion, vExpert, VMUG Leader ), e posso dizer que foram especiais os parâmetros para o CiscoChampion, onde fiz uma entrevista para DevNet Create para divulgar o evento no Brasil e também contar um pouco também sobre nossa comunidade no Brasil, sendo o primeiro blog brasileiro a difundir a informação sobre nossa comunidade e também de divulgar um resumo sobre o ” Kick Off “ executado com os líderes na abertura do evento.

Para nosso capítulo do VMUG São Paulo, onde nele conseguimos fazer 5 eventos durante o ano, com muitas palestras técnicas e também fizemos um encontro reunindo todos os capítulos do Brasil ( total de 6 ), onde foi chamado de VMUGão, inclusive com a presença ilustre de Sanjay Poonen ( COO ).

Certificações

Sobre esse quesito acredito que fiquei bem feliz, pois consegui desbravar algumas áreas que não são de meu cotidiano e posso dizer que vieram somente agregar mais conhecimentos para o dia a dia, e também ajudar no sentido de compartilhar mais tópicos para todos vocês que nos acompanham.

Dentro dessa trilha eu consegui obter a Certificação da Cisco ( CyberOps Associate ), Azure ( Fundamentals ), Aviatrix ( Engineer Multicloud ), Instrutor Netacad ( CyberOps Associate ), e um curso denominado BootCamp da IGTI ( Arquiteto de Cloud ).

Conclusão

Acredito que baseado neste resumo, posso dizer que foi um ano difícil, devido a diversos fatores que influenciaram durante a trajetória.

Tive os sucessos conforme demostrado acima, e que de uma certa forma foram excelentes, porém tenho que revelar que também tive deslizes, na qual teve a iniciativa de escrever um livro, onde não conseguimos evoluir, atualizar meu treinamento que também acabei não executando. Entretanto, acho que essas reflexões nos ajudam também a focar nas necessidades e avaliar para que não tenhamos punições se avaliar como um todo.

Como recomendação façam uma reflexão e sempre verifiquem os lados positivos, para que você não veja somente o lado negativo e possa se punir de forma injusta.

Abs,
Rodrigo

Meraki – Adicionar Aplicação Meraki Insight – Parte 4

Fri, 30 Oct 2020 00:00:00 +0000

Olá Pessoal,

Como todos vêem acompanhando nossos posts, eu fiquei demonstrar para vocês sobre a configuração especifica de uma aplicação dentro dos recursos do Meraki Insight.

Esse parâmetro é interessante, pois se a aplicação não existe dentro do portal, temos a opção de adicionar uma customizada para validar dentro dos 3 recursos disponivéis do Insight ( LAN, WAN, APP ).

Neste caso, escolhi fazer o post olhando para o Microsoft Teams, pois é uma aplicação do Office 365, e propriamente ela não esta separada dentro do portal Meraki.

Configuração

Como sempre as configurações são simples, e devemos ir no Configure Web Application -> Add a custom application.

Após esse processo uma tela irá surgir para definir o nome de sua aplicação, bem como qual será o dominio que seja consultar.

Obs.: Não é possível colocar range de endereços IPs, ele somente aceita nome de domínios.

Após esse processo já podemos consultar o ” Dashboard ” e verificar se temos nossa aplicação populada. Isso pode levar alguns minutos para ter os dados, pois a partir do momento que algum usuário interno em sua LAN começar a solicitar serviços para aplicação, consequentemente a ” probe “ irá iniciar através de seu MX.

Se você caiu de para-quedas nesse post, por algum, motivo recomendo ler os posts anteriores para entender de que forma essa ” probe ” funciona, bem como a funcionalidade do ” Smart Threshold ” que irá sempre observar através da origem para ter uma melhor resposta buscando esse serviço ( aplicação ).

Resultado

Após alguns minutos podemos avaliar se de fato, nossa validação especificamente nesta aplicação esta respondendo. Todos os gráficos serão demonstrado como já exposto no post anterior.

Neste caso vou demonstrar baseado no APP, e abaixo podemos avaliar que ele já respondeu para os endereços IP que respondem para serviço definido anteriormente.

Bem como, podemos avaliar quais são os dominios que estão respondendo para a máscara/dominio ( teams.microsoft.com ).

Para avaliar temos uma definição dos provedores, principalmente das aplicações definidas como SaaS ( Software as a Service ), para consultar os dominios e os endereços IPs que cada aplicação deve responder. Devido a isso temos esse documento da Microsoft Teams, que notifica qual o dominio é endereço IP são alocados.

Obs.: Vale lembrar que os endereços públicos muita das vezes podem alterar pelo provedor, e dependendo se você pensa em algo especifico em IP pode falhar. Existe um RSS que o provedor atualiza, que muitas das vezes em automação acaba respondendo muito mais rápido.

Conclusão

Conforme mencionado anteriormente a configuração é bem simples e intuitiva, bem como os resultados apresentados acabam sendo idênticos de uma aplicação que já esta mapeada pelo portal.

O que você achou dessa metodologia de configuração? Pode facilitar em nosso dia a dia?

Abs,
Rodrigo

Segurança – Exploração de Protocolos Autenticação – Dicas – Parte 3

Mon, 26 Oct 2020 00:00:00 +0000

Olá Pessoal,

Como vocês vem acompanhando nossos posts sobre o detalhamento de segurança na perspectivia inicial de um ambiente WI-FI, onde inicialmente trouxe a menção sobre a captura de pacotes usando ” air-crack “, em nosso segundo post foi explicado quais os pacotes são trafegados por esse ambiente, então espero nesse post falar um pouco sobre as metodologias que podem ser agregadas a esses ambientes.

Metodologias

Vale lembrar que as características mencionadas aqui, não necessariamente são aplicadas a somente ao ambiente de WIFI ou vice-versa, pois as soluções são intercambiavéis entre elas depedendo da característica de cada aplicação/solução.

Como estamos fazendo as tratativas em relação a conectividade e captura de pacotes via WIFI, então vou mencionar os tipos de criptografia, ou seja, os protocolos de segurança disponivéis para ser configurado.

WEP ( Wired Equivalent Privacy ): O protocolo foi desenvolvido em 1999, no entanto, existem diversos problemas de segurança conhecidos no WEP, bem como é fácil de ser quebrada a chave, baseando-se no tipo de ” hash ” que é executado. O protocolo foi oficialmente abandonado em 2004 pela WI-FI Alliance.
WPA ( WI-FI Protected Access ): Ele iniciou-se justamente com a idéia de melhorar o protocolo que usava-se na época ( WEP ), ou seja, ele foi lançado 1 ano antes de o WEP ser abandonado.

Na maioria dos casos WPA utiliza-se de uma chave pré-compartilhada ( PSK -> Pre-Share Key ) que por sua vez é adicionado em conjunto com TKIP ( Temporal Key Integrity Protocol ) e AES ( Advanced Encryption Standard ).

Lembrando que esse protocolo também é muito vulnerável, e ameaça maior é feita através do WPS ( WI-FI Protected Setup )

WPA2: Como devem imaginar ele é uma evolução de seu antecessor e a principal menção foi devido a ter adicionado um ítem importante que é a utilização do AES, bem como ela havia sido liberada pelo governo americano. Mas novamente, ainda existe um risco em relação a utilização do WPS que torna-se a sua rede mais vulnerável.

Dentro desse protocolo teremos também as mesmas menções citadas acimas, onde pode ser agregado com TKIP ou AES. Sempre o recomendado é você trabalhar com AES, pois o TKIP já foi excluido do WIFI Alliance, mas infelizmente alguns hardware ainda não suportam a utilização de criptografia AES, o que acarretá a você a trabalhar ainda com o TKIP.

Isso deve-se até porque a metodologia de processamento sendo usada para o AES é maior, e por muitas situaçõe se observar o equipamento, o mesmo pode deixar seu acesso mais lento.

WPA2 Enterprise: Neste modelo como podem imaginar estará mais relacionado algumas metodologias de autenticação diferenciada, que é especificamente se autenticar através de recursos externos ( RADIUS ) associados ao seu protocolo 802.1x. A ideia ainda não é se aprofundar neste paramêtro, porém ele acaba utilizando-se do EAP e normalmente iremos visualizar mais em ambientes corporativos, pois a implementação é mais complicada e nem todos os equipamentos suportam o 802.1x, dado na equação de visualizar em ambientes residencias.
WPA3: De fato é o novo protocolo liberado pela WIFI Alliance em 2018, e atualmente o mais seguro ( a principio – rs ). Como já alertado, hoje ainda muitos equipamentos não estão preparados para esse novo protocolo, bem como os endpoints para aceitar essa metodoliga de criptografia, mas acredito que mais 2 anos todos já vão estar utilizando esse protocolo.

Basicamente a ideia dele é proteger do famoso ataque de dicionário implementando a inovação sobre a troca de chaves. No WPA2 como vimos no post anterior utilizava-se de 4 vias entre o cliente e o AP para autenticar ( 4-way handshake authentication ), onde no WPA3 as senhas são mais difíceis de quebrar, pois o invasor precisa interagir diretamente com seu WI-FI para descobrir a senha, ficando mais doloroso o processo.

No WPA2 depois de capturado o trafego você poderia ficar executando o ataque dicionário por varios dias, semanas e meses, com isso conseguiria ver de forma clara seus dados. Entretanto, o WPA3 suporta o ” forward secrecy “, o que significa que se um atacante capturar quaisquer dados criptografados de sua máquina e depois aprender sua senha mais tarde, eles não serão capazes de decodificar os dados antigos que capturaram. Obviamente, eles só serão capazes de decodificar os dados recém-capturados, pois como mencionando acima precisa ser interagido diretamente.

Obs: Vale lembrar que baseado em todos esses modelos, de fato ainda não estamos totalmente resgardados em alguma dessas metodologias, pois as chaves podem ser capturadas, ou seja, a recomendação é sempre que use senhas fortes utilizando no mínimo 12 caracteres e sempre mesclar números, letras maiúsculas e minúscula, caracteres especiais.

Segue um dado que trafegou pela Internet, comparando a quantidade de caracteres X tempo. Infelizmente, não sei de onde veio esses dados, porém acredito que é interessante para pensar em suas metodologias de senhas.

Proteção

Após visualizar todos os protocolos acima, talvez você me pergunte estou confuso e temos muita ” sopa de letrinhas “, e de fato temos, e podem acreditar temos milhares ainda associadas a esses parâmetros.

Como podemos ter diferentes públicos lendo nosso BLOG, como usuários residencias e também de ambientes corporativos, vou tentar elencar da forma que vejo mais víavel para cada público, pois isso deve-se também sobre as questões de configurações que muita das vezes não é algo prático para o usuario final.

Residencial

Acredito que você pode observar em seu modem/router/WIFI para habilitar o protocolo nessa sequência e lembrando sempre sobre a criação da senha, pois ela é um dos principais fatores desse processo. Segue abaixo:

– WPA2+AES(PSK)
– WPA+AES(PSK)
– WPA2+TKIP(PSK)
– WPA+TKIP(PSK)
– WEP -> nunca 🙂
– Rede Aberta -> acredito que não existe a necessidade

Corporativo

Neste quesito podemos exigir um pouco mais pensando em sua infra-estrutura, bem como, pode solicitar serviços adicionais para autenticação. Segue abaixo:

– WPA2 Enterprise
– WPA2+AES(PSK)
– WPA3 ( analise para crescimento futuro )
– Rede Aberta -> Utilização de soluções NAC ( Network Access Control ), onde podemos explorar posteriormente.

Conclusão

Espero que vocês tenham gostado desses ítens adicionais, e possam ter explicado um pouco mais esses termos.

Caso você deseje mais informações sobre esses formatos, deixe seu comentário que podemos explorar mais esse conteúdo.

Agora vou deixar uma tarefa para vocês nesse post. Sobre qual tema vocês gostariam que fosse a parte 4 dessa série. Deixe sua dica que vou analisar e preparar o conteúdo.

Abs,
Rodrigo

Meraki – Analisar Gráficos Meraki Insight – Parte 3

Thu, 01 Oct 2020 00:00:00 +0000

Olá Pessoal,

De fato, já faz um tempo que trouxemos as informações relacionadas ao Meraki Insight, mas como sempre na correria acabo não conseguindo publicar todos os conteúdos ” on-time ” para vocês.

Mas, uma hora ele chega e acredito que possa ajudar todos vocês a entender um pouco a mais sobre as funcionalidades e a tecnologia. Enfim, depois demonstrar sobre as facilidades de configurações das aplicações que foram detalhadas em nosso post anterior, hoje venho aqui para explicar um pouco sobre os resultados que a solução vai nos trazer.

Detalhamento

Após mencionar sobre as diferentes formas de habilitar o serviço, digo em relação a utilização do ” Smart Threshold ” ou via os valores padrões, vamos sempre ter as segregações dos 3 componentes ( LAN, WAN, Aplicação ), com isso podemos observar através dos gráficos o que esta impactando a performance da minha aplicação.

Baseado-se nesse conceito, iremos ter as análises sendo populadas em nosso portal, e vale lembrar que as aplicações ou status de cada elemento irá ser definido com o status ” RED ” quando a performance ficar <80%.

Talvez venha a pergunta, posso alterar esse valor? Não, esse valor não pode ser alterado, ou seja, mesmo que você tenha uma aplicação WEB personalizada que irá monitorar seu servidor web, sempre irá seguir essa política.

Visualização da Organização

Neste meu caso vou observar toda minha organização, e dentro das ultimas duas horas, na qual observo apenas um alarme relacionado ao meu dropbox.

Entretanto, já temos que isso está relacionado com a aplicação, porém vamos observar todos os status na sequência.

Consolidação da LAN

Neste gráfico sempre iremos observar as caracteristicas internas de sua rede,

Como podem observar, consigo validar quantos clientes internos estão utilizando essa aplicação e se de alguma forma estão sendo impactados em relação ao serviço especificamente nesta aplicação.

Logo abaixo, podemos observar nos graficos se algo esta sendo impactado correlacionando ” GoodPut “, ” Loss “, ” Latency ” versus seu pior cliente interno.

Se observar no número ” 1 ” podemos observar sobre o meu cliente e através do número ” 2 ” poderiamos ver em relação a perca comparado o meu ” end point ” versus o serviço.

No gráfico abaixo podemos consolidar a latência e verificar quais os clientes estão utilizando essa aplicação, bem como quanto de solicitações estão sendo/foram requisitadas para este serviço.

Esses dados de fato não vão trazer a causa raiz do problema, pois podem existir outros fatores que estão impactando esses clientes, entretanto são dados que podem oferecer uma linha de raciocionio para iniciar as investigações posteriores através de outros ítens dentro de sua infra-estrutura, como se conectado ao WIFI qual seria o problema? Poderiamos avaliar no Wireless Health?

Consolidação da WAN

Nesses gráficos teremos a capacidade de avaliar a nossa conexão externa ( Internet ) entretanto com a visibilidade mais apurada para aplicação específica que estamos trabalhando neste momento.

Desta forma, logo abaixo como mencionado anteriormente teremos um resumo sobre componentes presentes nessa conexão e já poderíamos avaliar se temos impacto via nosso link.

Nesse caso, visualizamos que existe um período que de fato foi onde tivemos algumas oscilações relacionando ” goodput ” e ” loss “.

Abaixo verifico o que eu acho mais interessante, que é a latência, mas as questões de quais servidores de fato meu link WAN está buscando para essa aplicação, relacionando isso em perca, latência e quantidade de solicitações para os servidores na nuvem.

Obs.: Vale ressaltar que devido a estar trabalhando com o ” Smart Threshold ” esses servidores estariam relacionados a serem os mais próximos de onde estão conectado seu MX, mas sempre observe que muito serviço em cloud pode estar fazendo ” anycast ” ou dependendo da aplicação utilizando ” CDN “.

Para finalizar temos a menção resumida para todos os meus links, porém nesse caso tenho ativo um link de internet, mas se tivermos a conexão de mais circuitos podemos ter as estatisticas por link e atrelar isso também as menções sobre os recursos possiveis para atuar minha solução de SDWAN.

Consolidação da Aplicação

Enfim, chegamos no ítem relacionado aplicação que irá trazer mais valor no sentido de identificar os domínios e IPs que podem estar impactando em usa performance.

Logo abaixo, visualizo os gráficos que por sua vez vão definir qual é o tempo de resposta que estou tendo entre o MX e aplicação que esta hospedada na nuvem.

Nessa linha do tempo, consigo avaliar especificamente o tempo/latência dedicado para este período e validar com o impacto observado ou reclamação recebida através de seu usuário.

Logo abaixo a relação dos IPs que estão hospedando esse serviço, onde acabei deixando um filtro relacionado com a quantidade de solicitação.

Desta forma, podemos comparar rapidamente através da resolução desse endereço ( FQDN ) que temos o ponto em comum com o endereço IP versus a resolução do nome e a partir desse momento temos a confirmação que o impactante ou a baixa performance está relacionado a este serviço.

Conclusão

Podemos observar que de fato temos muito mais dados para trabalhar nos eventos de baixa performance, para assim comparar com nossa linha de base.

Porém, vale ressaltar que a partir do momento que você avaliou que sua aplicação está com baixa performance o troubleshooting juntamente como o provedor do serviço pode ser mais doloroso.

Entretanto, você terá muito mais dado para concretizar do problema que você esta enfrentando e assim encurtar o caminho, pois terá informações especificas do dominio, IPs, periodo, etc.

Em nosso próximo post vou configurar uma aplicação que de fato ainda não existe no portal especificamente e assim posso responder talvez mais um questionamento sobre esse ponto para vocês.

Fique ligado e deixe seu comentário para avaliar o que vocês estão achando dessas informações.

Abs,
Rodrigo

Segurança – Entendimento dos Pacotes na Rede WIFI – Parte 2

Wed, 26 Aug 2020 00:00:00 +0000

Olá Pessoal,

Estamos de volta para detalhar um pouco mais sobre o processo iniciado em nosso post anterior, relacionado sobre o ambiente de WIFI. Entretanto, a idéia agora seria explicar sobre os pacotes que viajam pelo nosso meio, bem como interpretar de forma clara a funcionalidade de cada processo.

Vale lembrar que todos esses dados exemplificados abaixo foram capturados através de um processo de monitoração ( escuta do ambiente ), ou seja, esses dados não são visiveis quando você já esta conectado em seu SSID.

Caso você queira visualizar os pacotes reais de trafego ( http, ftp, etc ), você irá seguir o processo idêntico quando você executa seu sniffer em uma rede cabeada, porém selecionando agora apenas sua interface WIFI. 🙂

Autenticação

A autenticação é o processo de comprovação da identidade de uma estação para outra estação ou AP. Em um sistema sem autenticação do usuário ( sistema aberto ), todas as estações são autenticadas sem qualquer verificação.

Como exemplo temos a estação ” A ” envia um quadro de gerenciamento de autenticação que contém a identidade de ” A “, para a estação ” B “. A estação ” B ” responde com um quadro que indica o reconhecimento ( ACK ), endereçado a A.

Na arquitetura de rede fechada, as estações devem conhecer o SSID do AP a fim de se conectarem ao AP, onde pode ser conhecido como ” Hidden SSID “, ou também podemos ter o exemplo de que o SSID pode ser visível para qualquer dispositvo ” BSSID “. A autenticação da chave compartilhada usa um desafio e uma resposta padrão juntamente com uma chave secreta compartilhada.

Logo abaixo, podemos observar os estágios sobre esse processo, lembrando-se que você estar autenticado não é significado que você esta associado ao seu AP. Outra menção, que nesta figura também iremos observar sobre ” Association “

Para que possamos comprovar, logo abaixo temos a captura do pacote para visualizar o que temos em cada cabeçalho no momento de ” Autenticação “. Eu removi alguns ítens para que não fique confuso, entretanto você também vão observar nessa captura que temos a visualização do QoS para essa conectividade.

Associação

Os dados podem ser trocados entre a estação e o AP somente após uma estação ser associada a um AP ( Modo Tradicional ) ou com outra estação no modo ” ad hoc “. Todos os APs transmitem frames ” Beacon ” algumas vezes por segundo que contêm o SSID, tempo, capacidades, taxas suportadas, bem como as estações podem optar por associar-se a um AP em relação a sua intensidade de sinal de cada AP, etc.

A associação é um processo de duas etapas. Uma estação que atualmente não está autenticada e não associada escuta os frames ” Beacon “. A estação seleciona um BSS para se associar, após isso a estação e o AP se autenticam mutuamente, trocando as estruturas de gerenciamento de autenticação. O cliente agora está autenticado, mas não associado.

Na segunda etapa, a estação envia um quadro de Pedido de Associação, ao qual o AP responde com um quadro de Resposta de Associação que inclui um ID de Associação para a estação. A estação é agora autenticada e associada.

Para exemplificar podemos visualizar abaixo o estado de solicitação, na qual o esta sendo solicitado especificamente para um SSID ” ap34b “, e logo abaixo também já podemos visualizar sobre a capacidades de largura de banda pode suportar.

Como exposto, temos agora a nossa resposta a nossa solicitação.

PS.: Uma estação pode ser autenticada com vários APs ao mesmo tempo ( modo clássico onde ficam salvo todos os SSIDs no seu endpoint ), mas associada com no máximo um AP a qualquer momento. A associação implica em autenticação. Não há nenhum estado onde uma estação é associada mas não autenticada.

De-Authentication

Esse processo pode ser considerado ou co-relacionado como ” Man-in-the-Middle “, pois a proposto é enviar pacotes para o AP alertando que o cliente com o seu específico ” mac source address ” foi desautenticado e por essa característica o cliente vai solicitar novamente o processo de autenticação entre cliente->AP.

O que ocorre, é a execução de um ” flood ” de pacotes para justamente fazer com o cliente fique tentando se autenticar e como mencionado podemos relacionar o ” man-in-the-middle ” e capturar esses pacotes que estão trafegando pelo nosso meio. Logo abaixo podemos ter um exemplo do que é mencionado.

Como sempre precisamos demonstrar sobre essa caracteristicas visualizando nosso pacote sempre observando que estamos tendo nossa origem e destino.

Acredito que vocês devem estar perguntando sobre o filto aplicado no Wireshark. Pois bem, existem as flags que podemos controlar desta forma fica mais facil a visualização. Como facilidade segue o parâmetro e logo abaixo temos uma tabela com os principais valores para o filtro.

(wlan.fc.type == 0) && (wlan.fc.type_subtype == 12)

Segue nossa tabela abaixo:


Frame Type/Subtype	Filter
Management Frames	wlan.fc.type eq 0
Control Frames	wlan.fc.type eq 1
Data Frames	wlan.fc.type eq 2
Association Request	wlan.fc.type_subtype eq 0
Association Response	wlan.fc.type_subtype eq 1
Reassociation Request	wlan.fc.type_subtype eq 2
Reassociation Response	wlan.fc.type_subtype eq 3
Probe Request	wlan.fc.type_subtype eq 4
Probe Response	wlan.fc.type_subtype eq 5
Beacon	wlan.fc.type_subtype eq 8
Announcement Traffic Indication MAP (ATIM)	wlan.fc.type_subtype eq 9
Disassociate	wlan.fc.type_subtype eq 10
Authentication	wlan.fc.type_subtype eq 11
Deauthentication	wlan.fc.type_subtype eq 12
Action Frames	wlan.fc.type_subtype eq 13
Request to Send	wlan.fc.type_subtype eq 27
Clear to Send	wlan.fc.type_subtype eq 28
ACK	wlan.fc.type_subtype eq 29

PS.: Vale ressaltar que esse spoof pode ser detectado pelo seu AP, obviamente se ele suporta essa característica, bem como hoje temos modelo de APs / Fabricantes que dedicam exclusivamente um radio para ficar visualizando isso na rede e por consequencia irá bloquear esses pacotes ou mesmo jogar a origem do spoof para uma blacklist.

Beacon

A definição para um ” Beacon Frame ” é de fato aquele pacote que fica sendo anunciado pelos APs ou até mesmo esses equipamentos de IoT ( Internet of Thing ) periodicamente para a rede, ou seja, para aquele ambiente que temos sinal sendo publicado para a infraestrutura.

Basicamente ele é um pacote de gerenciamento do 802.11, que contm todas as informações dos BSS ( Basic Service Set ), que por consequencia irá levar o nome de nosso famoso SSID, desta forma qualquer device escutando esses beacons irá interpretar que tem esse caminho para associar-se aquela infraestrutura.

Abaixo temos um exemplo de um pacote capturado com a flag de ” Beacon “, onde podemos observar sobre o anúncio do nome do SSID, bem como pegar que o endereço destino é de fato um broadcast. Logo na sequencia o periodo que estes beacon estão sendo transmitidos.

PS.: Uma informação para vocês pensarem e pesquisarem, pois não vou explorar esse tópico, mas não é uma boa pratica criar diversos SSID para segregar diferentes aplicações, acessos, regras, pois sua performance pode degradar em seus equipamentos.

EAPOL ( Extensible Authentication Protocol Over LAN )

Enfim, chegamos no protocolo que é utilizado para que possamos carregar nossa autenticação não somente do WIFI, mas é um protocolo usado por outras tecnologias.

A autenticação 802.1X envolve três partes: um suplicante, um autenticador e um servidor de autenticação. O suplicante é um dispositivo cliente (como um laptop) que deseja associar-se à LAN/WLAN. O termo ” supplicant ” também é usado de forma intercambiável para se referir ao software executado no cliente que fornece credenciais ao autenticador. O autenticador é um dispositivo de rede que fornece um link de dados entre o cliente e a rede e pode permitir ou bloquear o tráfego de rede entre os dois, como um switch Ethernet ou ponto de acesso sem fio; e o servidor de autenticação é normalmente um servidor confiável que pode receber e responder a solicitações de acesso à rede, e pode dizer ao autenticador se a conexão deve ser permitida, e várias configurações que devem se aplicar à conexão ou configuração desse cliente.

Logo abaixo, temos um exemplo sobre esses processo observando os frames que são trafegados.

Trazendo para nosso exemplo, após completar os processo de ” Association Request ” e ” Association Response “, já mencionados acima teremos de fato a troca das chaves que esta associado aos pacotes capturados abaixo:

Podem observar que temos a menção de 4 ” Key Message ” que é a troca existente utilizada no procolo para garantir essa comunicação e obviamente garantir a utilização das chaves definidas neste processo.

Para facilitar no filtro em seu arquivo Wireshark pode-se utilizar a menção:

eapol.keydes.type == 2

Conclusão

Hoje vocês puderam entender um pouco mais sobre os pacotes que trafegam por este meio, com o intuito de avaliar quais os parâmetros principais são utilizados para identificar sua rede e obviamente executar sua autenticação.

Vale lembrar que não foi aprofundado sobre os protocolos de criptografia utilizados para esse processo de autenticação, mas por alguns screenshot espero que vocês possam ter observado esses detalhes.

O que vocês acharam? Muito teórico os ítens abordados? Você acredita que pode trazer um entendimento melhor do funcionamento para agregar segurança em sua rede? Responda em nossos comentários e deixe-me saber o que você esta achando/observando/pensando. 🙂

Em nosso próximo post vou mencionar sobre esse quesito da segurança, já que estamos expostos para que nossos pacotes sejam capturados de qualquer forma em um ambiente que pode estar exposto a qualquer indivíduo.

Abs,
Rodrigo

Meraki – Iniciar o serviço para analise do Meraki Insight – parte 2

Tue, 11 Aug 2020 00:00:00 +0000

Olá Pessoal,

Conforme mencionado em nosso post anterior, hoje iremos demonstrar como habilitar o serviço e analisar alguns itens a partir desse recurso.

Vale lembrar que se você caiu nesse post de para-quedas procurando pelo tópico sobre Meraki Insight, eu recomendo você olhar nosso post anterior, desta forma você irá entender melhor a proposta para essa funcionalidade.

Habilitar o serviço

Quando falamos em trabalhar com o serviço “ Insight “, de fato para termos essa funcionalidade, precisamos validar se nossa licença está aplicada para sua organização.

Consequentemente, caso esteja operacional o menu para configuração e validação do status irá aparecer na lateral à esquerda.

Se por algum motivo em sua organização tiver problemas sobre o licenciamento, a mensagem que pode aparecer em seu “ Dashboard “ seria nesse formato.

Validação dos dados

Tradicionalmente como somos do ambiente de Networking / Enterprise / WAN nosso primeiro ítem para vallidar estará atrelado ao “ WAN Health “. Para consolidarmos, os dados são populados referenciando-se a cada MX, que obviamente será aquele que você tem a licença habilitada em sua organização.

Com isso iremos ter esse “ Overview “, lembrando-se que em meu caso estou utilizando apenas um MX.

Como podem observar já temos algumas informações consolidadas nessa visualização. Eu tenho dois endereços IPs que está validando meu mundo externo ( os IPs podem ser configurados ), lembrando que o DNS Cisco/OpenDNS foi incluido para obter métricas diferenciadas e também para observar nessa “ View “ , as diferenças que podemos ter entre esses dois destinos. Pense, que esse histórico pode ser utilizado em diferentes perspectivas, pois podemos consolidar a disponibilidade que esse link está me oferecendo, se a banda ofertada está sendo atendida, se o site está trabalhando no limite de banda, estamos utilizando primario/secundário, etc.

Caso você tenha uma conexão utilizando LTE, ela também pode ser validada, mas vale lembrar que esse parâmetro irá ser demonstrado apenas com aquele circuito que está operacional, ou seja, o circuito primário que está consumindo banda.

Desta forma, já podemos ter diferentes insumos para observar alguns problemas que são vivenciados em nosso dia-a-dia. O que você achou?

Web Health

Nesta categoria que teremos nossa validação para os serviços em Cloud, e consequentemente nela que iremos habilitar quais são os serviços que são mais importantes para seu negócio.

Talvez vocês me perguntem, quero habilitar para todos os serviços, desta forma eu sei de tudo que está acontecendo, está correto?

Não. A principio existe uma recomendação para que você não deixe mais de 10 serviços ao mesmo tempo sendo monitorando pelo seu MX, isso porque vai consumir muito recurso de seu equipamento e também como explicado no post anterior, ele precisa ficar enviando as probes para essas aplicações.

Hoje já temos diversas aplicações mapeadas pela ferramenta e podem ser escolhidas rapidamente, através ” Insight -> Web App Health -> Configure Web Applications “.

Agora podemos escolher dentro das diversas categorias, aplicações mais reconhecidas para seu negócio, assim você pode observar a performance dela em seu ambiente.

Em meu exemplo selecionei algumas aplicações relacionadas armazenamento, música, chat, aplicação como SaaS. Após esse processo já teremos todas as aplicações populadas e já começamos a visualizar os 3 segmentos ( LAN, WAN, Server )

Como podem notar, estou visualizado esse histórico baseando-se no mínimo periodo que seria de 2 horas, porém podemos pegar esse valores de 1 semana atrás. Talvez vocês me perguntem, qual a diferença entre o ” Edit “ e o ” Smart Threshold “?

De fato é uma ” feature “ muito interessante, por isso até deixei marcado, pois temos uma grande diferença pensando como um projeto global ou até mesmo baseando-se por diferentes regiões. Porquê?

Pense que cada MX espalhado por usa infra, com diferentes provedores de ” last mile “, e muitas vezes podemos pensar que determinados sites podem estar mais próximos de algumas aplicações ( distância física, etc ) do que outras que são hosteadas em diferentes Datacenter, co-relacionado com cada provedor de serviço em Cloud. Portanto, quando temos a opção ” Edit “, teremos os valores padrões já carregados pela ferramenta.

Caso você deseje alterar é somente usar o mouse para arrastar para os valores desejados. 🙂

Quando selecionado o ” Smart Threshold “ a própria solução vai avaliar relacionando essa aplicação os valores aceitavéis, pois esse site pode estar com um link WAN de performance alterada devido aumentar latência para chegar naquele destino, ou até mesmo por esse site estar numa região afastadas fisicamente das soluções hosteadas. Caso tenha mais dúvidas recomendo olhar esse link.

Conclusão

Como já mencionado a solução está atrelada com todos esses artefatos, onde traz uma visibilidade muito mais apurada, oferecendo uma maior segurança para seu dia a dia em analisar os problemas que são vivenciados com essas aplicações em Cloud. O que você achou?

Em nosso próximo vou demonstrar os gráficos com essas aplicações para entendermos como poderíamos agir em nosso dia a dia.

Abs,
Rodrigo

Segurança – Analise de WIFI – Entendimento via Air-Crack

Mon, 03 Aug 2020 00:00:00 +0000

Olá Pessoal,

Como vocês sabem nosso BLOG acaba tendo uma diversidade de conteúdo e nem sempre seguimos uma linha, adicionando apenas conteúdo específico daquela tecnologia ou dedicado aquele fabricante.

Meu objetivo aqui é sempre compartilhar um pouco daquilo que eu estudo, aprendo, bem como ítens que preciso pesquisar e obviamente aprender, pois como sabem também leciono. Devido a isso, sempre precisamos encontrar maneiras para explicar conteúdo específicos ou até de criar laboratórios para explicar determinado funcionamento dentro de nosso ambiente.

Desta forma, hoje iremos ter um conteúdo totalmente diferente que é explicar um pouco sobre Wireless, utilizando algumas análises de ferramentas que ouviamos falar bastante em nosso meio. As ferramentas mencionadas, podem ser utilizadas para critérios de avaliação de segurança em sua infra, ou pode ser utilizada por pessoas mal-intecionadas para usufruir desse descuidado dos usuários em ambientes compartilhados.

Vale lembrar!!! O que iremos detalhar tem a intenção disseminar ítens para conhecimento no âmbito para entendimento do funcionamento da tecnologia, e correção de falhas para seu ambiente. Todo ato mal intencionado é por conta e risco de cada usuario e não temos nenhuma responsabilidade.

Para conhecimento a ferramenta que iremos utilizar será AirCrack-ng.

Talvez muito de vocês vão perguntar. Porque você não fez isso usando o Kali Linux? Porquê precisamos usar uma ferramenta de PenTest para aprender?

A ideia aqui é explorar os caminhos, pois essas bibliotecas não são exclusivas da distribuição Kali Linux, e sim pode ser instalada qualquer distribuição ( inclusive Windows ). Não necessariamente é uma ferramenta de pentest, mas sim algo que você possa entender o que de fato está ocorrendo em sua conectividade WIFI.

Instalação

Neste exemplo, vou executar a instalação “default” dos pacotes através disponibilização feita pela distribuição instalada na máquina virtual (XUBUNTU-18.04). Desta forma segue abaixo:

Podemos observar a versão instalada:

root@ubuntu:/home/rodrigo# aircrack-ng --help

Aircrack-ng 1.2 rc4 - (C) 2006-2015 Thomas d'Otreppe
http://www.aircrack-ng.org

usage: aircrack-ng [options] <.cap / .ivs file(s)>

Obviamente a melhor forma seria adicionar o repositório, porém algumas pessoas não gostam devido a não ter homologação da distribuição em seus respositórios. Entretanto, para que você possa sempre obter a última atualização do código, pode ser executado conforme abaixo. Caso tenha interesse de ler mais sobre esse desenvolvimento, recomendo olhar a documentação.

$curl -s https://packagecloud.io/install/repositories/aircrack-ng/git/script.deb.sh | sudo bash

root@ubuntu:/home/rodrigo# aircrack-ng --help

Aircrack-ng 1.6 rev cd77600 - (C) 2006-2020 Thomas d'Otreppe
https://www.aircrack-ng.org

usage: aircrack-ng [options] <input file(s)>

Funcionalidades

Após consolidação da instalação podemos observar algumas formas de avaliar os comandos disponivéis através dessa biblioteca, e para nosso exemplo iremos utilizar:

airmon-ng: Processo para consolidação sobre se nossa porta ( conectividade ) WIFI irá monitorar o tráfego, ou seja, trazer a concepção de que estou trabalhando em ” Monitor Mode ” ou ” Managed Mode “.
airodump-ng: Processo para capturar os pacotes que estão sendo escutados pela sua conectividade WIFI, em modo de ” Monitor Mode “.
aireplay-ng: Processo para gerar tráfego na rede, tendo o propósito de capturar pacotes de “deauthentication” para usufruir deles com intenção da visualização dos pacotes.
aircrack-ng: Processo para executar “brute-force” nos dados capturados e avaliar a segurança da conectividade.

Inicialização dos comandos

Para que você consiga monitorar através de sua conexão WIFI, já mencionado acima terá que iniciar sua placa ou USB em modo ” Monitor “, para validar é interessante executar as validações:

$ sudo airmon-ng check

Caso seja necessário você pode matar o processo para iniciar em modo monitor

$ sudo airmon-ng check kill

Consolidar iniciando

$ ip a ( para capturar o nome definido da placa )

$ sudo airmon-ng start wlan0

A nomenclatura wlan0 pode modificar validando o que de fato o seu SO ( Sistema Operacional ) identificou para essa conectividade WIFI. Baseado em seu output, você precisa nesse momento fazer a referência conforme evidenciado, na qual em meu caso ele definiu para **wlan0mon**

PS.: Pode ser que seu USB não suporte a menção para atuar como “monitor”, portanto terá que avaliar um novo dispositivo ou pesquisar sobre o device.

Capturar os BSSID co-relacionado com os APs próximos, e mapear o nome do SSID.

$ sudo airodump-ng wlan0mon

Para que possamos acelerar o processo de captura podemos forçar a DE-AUTH dos endpoints, mas faça com cautela pois isso pode impactar a rede e também existe a forma de captura de seu MAC-Address.

$ sudo aireplay-ng --deauth 1000 -a [ MAC AP Destino ] -c [ MAC Endpoint Destino ] wlan0mon --ignore-negative-one

Proximo passo é começar a capturar dados para obter o handshake entre o AP e o host ( usuario ). Observe para validar em qual canal esta operando essa comunicação.

$ sudo airodump-ng -c [ canal ] --bssid [ MAC AP Destino ] -w [ nome do arquivo salva a captura.pcap ] wlan0mon --ignore-negative-one

PS.: Depois de rodar por algum tempo devemos observar se iremos obter algo no sentido de **WPA handshake: BSSID**, ou seja, caso isso ocorra você já conseguiu obter a captura do pacote que esta contido o handshake de autenticação.

Outro lembrete que caso queira visualizar outras formas/combinações, é possivel também utilizar sempre o comando de ” help ” de cada comando para lembrar o que de fato você tem necessidade para visualizar.

E agora?

Obviamente sempre irá ter a pergunta. E agora o que faço com isso?

Na verdade temos um caminhão de informação capturada que irei explicar em outros post, pois vamos analisar através do Wireshark, mas de fato temos agora os dados e precisamos unicamente tentar fazer um ” brute-force “. Mas para isso existe milhões de opções para esse caso, e os mais tradicionais são as ” Word Lists “.

A mais conhecida seria chamada de ” John the Ripper “, onde tem listas com milhões de combinações.

Você pode fazer um teste criando uma lista rapida apenas para validar e entender o funcionamento, porém novamente, não temos a intenção aqui de trazer risco para vocês, então fique claro que isso fica a critério de cada usuario.

Para efetuar brute force, segue o exemplo:

$ aircrack-ng -w Downloads/teste.txt -b [ MAC AP Destino ] pacote_capturado.pcap

Esse processo pode demorar horas ou segundos, variando em relação ao tamanho de sua ” Word List “, ou a complexidade da senha criada. Lembrete, pode ser que depois de rodar horas você ainda não consiga obter a senha, pois não existe a senha no seu arquivo de teste. 🙂

Conclusão

Neste caso apenas quis compartilhar os ítens que foi pesquisado e também para alavancar novos conteúdos em relação essa tecnologia.

Como mencionado vou trazer nos post posteriores uma explicação sobre esses pacotes capturados, como eles são trafegados em nosso ambiente e também algumas dicas de como se prevenir para melhorar sua segurança.

Espero que tenha gostado e postem seus comentários abaixo se gostaram, se é valido explorarmos esse mundo.

Abs,
Rodrigo

BLOG – Primeiro post sobre Python

Tue, 23 Jun 2020 00:00:00 +0000

Olá Pessoal,

Como podem observar pelo título, digo que hoje será nosso primeiro post efetivamente relacionado a Python, e de fato tenho que mencionar que vocês também estão certo, pois podemos começar uma nova jornada aqui em nosso BLOG.

Como vocês podem notar em nosso BLOG, eu sempre tento desenvolver algo que de fato é motivacional para mim buscar a informação, pesquisar, desenvolver, concluir, testar e depois tento compartilhar com vocês essa ideia, que por sua vez pode ajudar algum de vocês e também sempre aprendo algo à mais com vocês.

Projeto

Esse papo iniciou-se em um dos grupos e acabei me interessando na ideia, pois de momento pensei em 4 formas para poder utilizar essas facilidades:

Ambiente corporativo tanto a nível de TI Interno, como também para empresas de terceiros, que em muitos casos precisamos executar troubleshooting.
Nível de usuario domestico, para ter algum historico e avaliar se esta de acordo com os planos contratados.
Executar um teste em guest shell em roteadores Cisco rodando diretamente o script Python.
Para aprendizagem sobre os conceitos de Python.

SpeedTest

Acredito que a maioria de vocês em algum momento já utilizou o site do SpeedTest ou qualquer outra variação nesse sentido ( Fast – Netflix, Brasil Banda Larga, OKLA, Cloudflare, etc ).

Talvez muitos de vocês vão achar que estou sendo maluco, pois esses testes muito das vezes não significam muito em troubleshooting, pois nem sempre os valores indicados são reais, já que sempre irá buscar o servidor mais proximo de seu ponto, depende também da disponibilidade desse provedor, não tem preferência esse tráfego, os servidores que estão medindo esse tráfego nem sempre estão disponivéis em estruturas dedicadas, etc.

Também concordo nesses ítens, mas foi um aprendizado para eu aplicar algo em Python, então sempre olhe com outra perspectiva seu aprendizado. Pode ser, que para alguma situação de um leitor, isso possa ser útil, então por isso resolvi compartilhar e não guardar a informação comigo. 🙂

Devemos lembrar que temos uma biblioteca Python definida como speedtest-cli, ou seja, não iremos precisar utilizar um navegador para obter os valores.

Lab

Nesse laboratório utilizei alguns outros conceitos que depois posso detalhar em outros posts, pois a ideia é que esse teste fique em execução, assim pode-se fazer a validação conforme sua necessidade, ou seja, para nosso exemplo eu fiz com que meu script execute automaticamente a cada 30 minutos.

Após esse período, ele irá passar as informações desejadas para um dashboard, onde iremos poder consultar essas informações através da Internet. Esse ambiente que temos é free, porém temos algumas ressalvas, pois a base de dados que fica guardada no dashboard é de 30 dias, podemos ter apenas 3 devices cadastrados e no máximo cada dashboard desses devices pode ter 10 gráficos. A ferramenta que utilizei foi da Ubidots, mas como informado o plano free atende muito bem para estruturar seus testes e ” brincadeiras…rs “.

Segue a estrutura:

Docker Ubuntu – image 18.04
1. Python 2.7
2. Crontab
3. speedtest-cli
4. Python Library request
Conta na Ubidots
Link de Internet ( rsrs )

Código

Conforme mencionando anteriormente iremos utilizar algumas bibliotecas do Python, e a partir dela iremos utilizar as variáveis para construir nosso código. Não tenho também a ideia de explicar toda a estrutura do Python neste momento, pois espero publicar mais ” 101 – Python “ para trazer testes mais lógico e simples.

Com isso, segue o código definido para essa tarefa. Se observarem o código também já esta explicando cada funcionalidade.

#!/usr/bin/python
import speedtest
import requests

#Global variables
ENDPOINT = "things.ubidots.com" #URL related webpage to create dashboard
DEVICE_LABEL = "raspberry-pi" #Not necessary to be raspeberry and can use any linux inside container or run in your machine
VARIABLE_LABEL = "city" #Variable created inside Ubidots portal
TOKEN = "YOUR TOKEN"

#Get value related your connection using library SpeedTest
st = speedtest.Speedtest()

#Get values related class of server near of your provider
st.get_best_server()

#Execute Post Related City and Provider of SpeedTest
def post_var(payload_ci_sp, url=ENDPOINT, device=DEVICE_LABEL, token=TOKEN):
    url = "http://{}/api/v1.6/devices/{}".format(url, device)
    headers = {"X-Auth-Token": TOKEN, "Content-Type": "application/json"}

    if VARIABLE_LABEL == 'city':
        req = requests.post(url=url, headers=headers, json=payload_ci_sp)

    else:
        print("Error with variable City")

#Main function to capture payload each variable(city,provider)
def main():
    # Builds Payload and topic
    payload_ci_sp = {VARIABLE_LABEL: {"value": 30, "context": {"city": st.best['name'], "provider": st.best['sponsor']}}}

    #Send Data
    post_var(payload_ci_sp)

#It only to execute main function + post_var
if __name__ == "__main__":
    main()

#Capture all values related your connection
payload = {'Download': round(st.download() / 1000000, 2) , 'Upload': round(st.upload() / 1000000, 2), 'Ping': round(st.results.ping, 2)}

#Execute post of values
r = requests.post('http://things.ubidots.com/api/v1.6/devices/raspberry-pi/?token='TOKEN'', data=payload)

Dashboard

Após essa estrutura iremos avaliar se de fato as informações estão sendo populadas no portal da Ubidots. Vale lembrar que é necessário abrir uma conta no portal e também gerar uma ” API Key “, pois é através dessa API que você irá conseguir popular suas informações.

Uma outra dica é que para esse dashboard, as variáveis serão populadas através da estrutura como sendo um ” Raspberry PI “, porém como explicado acima não existe a necessidade de ter o equipamento, pois você pode executar através de qualquer equipamento baseando-se em Python 2.7 e versões posteriores.

Isso foi uma forma de utilizar essa facilidade de APIs do fabricante, que já disponibiliza isso através de seu dashboard.

Após obter as informações populadas, você pode montar seu dashboard da forma que achar mais interessante. Eu acabei colocando desta forma.

PS.: Eu coloquei também diferença de cores para simbolizar alguns limites que podem demonstrar para você, como amarelo o threshold 1 já excedeu.

Neste caso acima estou populado os valores bem como mostrando as variavéis que escolhi no meu código Python para representar ” City “ e ” Provider “.

Conclusão

Neste desenvolvimento tentei de fato mais aprender a trabalhar com o Python, bem como tentar transferir informações para outras plataformas, do que propriamente o fato de ser o teste do SpeedTest. Acho que isso de alguma forma incentivou para usar uma situação real e transformar ela em algo mais palpável, do que visualizar isso através de um Browser.

O que vocês acharam? Qual sua opinião sobre a utilização do SpeedTest? Tem pensando em alguma facilidade utilizando Python?

Descreva abaixo em nossos comentários. 🙂

Vale ressaltar que esses códigos eu já havia populado no Github, então se deseja ter mais detalhes ou se deseja contribuir mais com o código fique a vontade. Vai lá para dar uma conferida -> Inet_Validation_Speed

PS.: Um dos testes que estou achando bem mais interessante hoje é da CloudFlare, que tem mostrando o jitter e as variações por banda.

Abs,
Rodrigo

BLOG – Cisco Meraki – Wireless Health – O que é?

Mon, 30 Mar 2020 00:00:00 +0000

Olá Pessoal,

De fato temos muito conteúdo de Meraki em nosso BLOG, devido à isso gostaria novamente de trazer outro conteúdo para agregar conhecimento a todos, obviamente como esta solução está crescendo em clientes, acredito que é sempre relevante adicionar esses ítens e também para que eu possa aprender junto com vocês.

Wireless Health

Hoje em dia nosso ambiente residencial e corporativo está cada vez mais crescendo nas estruturas de WIFI

do que propriamente pela infra cabeada, isso se dá por alguns fatores que acredito que vocês possam imaginar.

Com isso, à partir do momento que você pode usufrir de alguns logs, messagens, notificações, recomendações de seu ambiente WIFI sempre é glorioso, portanto no dashboard Meraki temos algumas dessas informações para nos ajudar em nosso dia a dia.

Para ressaltar sobre essa funcionalidade é importante que seu MR esteja com software mínimo 24.12. Não há necessidade nenhuma de licença adicional para visualizar essas informações.

Exercendo consulta através do AP

Como informado acima podemos executar essa consulta através do AP ( Access Point ). Para isso devemos ir Wireless -> Access Point -> Historical Data, e obter os dados conforme abaixo.

Como podemos observar nesse dia eu já conseguiria ter informações relacionados aos problemas mais vivenciados ( Association, Authentication ). Entretanto, essas não são as únicas mensagens que podem aparecer, ou seja, podemos visualizar também ( DHCP, DNS ), assim podemos detalhar:

1. Association: Sucesso para se associar ao AP dentro daquele tempo especifico.
2. Authentication: Clientes fizeram associação, porém no momento de confirmação ( WPA/WPA2 ) teve uma falha. Vale lembrar que como os ítens estão associados no momento que falha autenticação ele também irá incrementar no ” association “
3. DHCP: Clientes associados e autenticados, porém teve problemas para receber um IP valido do servidor de DHCP
4. DNS: Clientes que executaram os 3 passos anteriores, entretanto pode por algum motivo não ter conseguido resolver nomes.

Device mais impactado

Seguindo com nossa validação, podemos consultar baseado no maior problema encontrado acima como sendo ” Autentication “ e validar em qual SSID e se tivermos diversos APs consolidar em qual deles isso está ocorrendo com maior frequência.

Após isso, podemos verificar qual o device que impactou, bem como ao mesmo tempo verificar se ele está conectado no momento ou não.

Logo abaixo você pode avaliar através de um outro device que temos uma porcentagem de ” Success “ e como está a ” Latency “ desse dispositivo final e verificar se está conectado e o quanto ele utilizando de ” throughput “.

Agora podemos visualizar pela perpesctiva do AP esse cliente, e validar qual o canal ele está usando, bem como se quisermos já podemos executar um ” ping “ ou ” packet capture “ identificando o que está passando nessa conexão.

Enfim, agora gostaria demonstrar que podemos ter todos esses dados consolidados através do menu mencionado acima e assim obter todas as estátisticas. Neste exemplo obtive a tela sobre as conectividades e podemos observar mais abaixo que os devices que tiveram problemas.

Visualização Latência

Outro dado importante que pode nos ajudar é relacionado a qualidade de serviço que temos dentro de nosso ambiente de WIFI. Para nosso exemplo que eu estava como maior latência para o tráfego de video e qual era o device que estava sendo mais impactado.

Vale ressaltar que nesse exemplo eu não havia aplicado nenhuma politica de QoS para os serviços, portanto eu estava com o padrão.

Logs

Enfim, chegamos em um dado também interessante que é visualizar nossos logs correlacionando com os eventos que mencionamos acima.

Conclusão

Neste caso acredito que temos informações que podem nos ajudar em nosso dia a dia, bem como identificar a causa raiz de alguns problemas que vivenciamos em ambientes WIFI que não necessariamente esta relacionado com cobertura, latência, qualidade de serviço. Porém, vale ressaltar que se tivermos em nosso ambiente um switch que não seja Meraki, todo esse historico será perdido e não iremos identificar em algumas situações o real problema de sua infra, pois aqui podemos obter dados de perca de pacote, gargalo em portas, etc.

O que vocês acharam desses outputs? Eles ajudam obter dados para identificar problemas? Deixem seus comentários!!!

Abs,
Rodrigo

**Fonte:**Documentação Meraki Wireless Health

BLOG – Cisco Meraki – MR Per Device License + Umbrella

Thu, 19 Mar 2020 00:00:00 +0000

Olá Pessoal,

Acredito que depois de um longo periodo, sem escrever sobre Meraki, hoje venho aqui para demonstrar mais um ítem que eu acho muito válido, pois foi lançado recentemente como sendo uma alternativa para ambientes específicos ( shows, eventos, escritórios, etc ), na qual consiste de obter um adicional de segurança ( Umbrella ) diretamente via MR ( access point ), sem obter um UTM ( Firewall ).

Essa demora também deve-se alguns problemas que obtive para conseguir colocar para funcionar no portal, pois eu tinha equipamento associado a licença ( co-termination ), que pertencia ao meu kit adquirido via CMNA, devido a isso outros eventos ocorreram para colocar em funcionamento, abrindo um ticket e ” calls ” com time da Meraki, entretanto agora vou conseguir detalhar para vocês sobre essa novidade/facilidade.

Licenciamento

Vale ressaltar que essa funcionalidade nos MRs só é possível executar a partir do momento que você transforma sua Organization na categoria de licenciamento por device, ou seja, você precisa atrelar as novas demandas de licenciamento do fabricante que ficará amarrado especificamente por equipamento

Se deseja saber mais sobre a mudança do licenciamento recomendo acessar esse link, e reforço que a partir do momento que você muda para ” Per License “ você não pode voltar para o modelo antigo de licenciamento “Co-Termination”

Per Device license

Como explicado anteriormente, é obrigatório alterar nosso licenciamento, devido a isso, bem como para ter a função ” Umbrella “ funcional precisamos ter licença ” Advanced Security “. Segue abaixo a menção do licenciamento.

Como nosso foco não é mostrar como fazer alteração para ” Per-License “ no Portal, recomendo também a ler esse documento. Se vocês tiverem dúvida, acredito que não, pois esta bem detalhado a documentação, deixe nos comentários sua duvida e tentamos ajudar, ou posso no futuro fazer um post demonstrando. 🙂

Configuração inicial

Se você já acompanhou nossos posts anteriores explicando sobre o Umbrella na plataforma Meraki, vai observar que existe alguma similaridade nas configurações, entretanto neste caso não iremos precisar executar alguns passos anteriores para sincronizar com o Dashboard Umbrella.

Esse é o ponto interessante que agora não teremos dois paineis para fazer nossas configurações, e sim somente via Meraki onde esses parametros já são executados.

Você pode observar que o parâmetro que tinhamos via Network Wide -> General irá aparecer uma mensagem, onde nos posts anteriores podiamos observar que era o campo para inserirmos a chave ” API “ para sincronizar as ferramentas

Portanto, agora nossas configurações serão diretas via ” Firewall & Traffic Shapping “ e ” Group Policies “.

Firewall Traffic Shapping

Conforme nos procedimentos ja explicados nos posts anteriores de Umbrella, neste ponto temos as mesmas menções, porém a partir do momento que você habilita a conectividade com o ” Umbrella “ já veremos que existem varias politicas definidas para você escolher e cada uma vai representar um nível de filtro, baseado já nas categorias tradicionais do Umbrella ( lembrando também antigo conhecido nosso OpenDNS ). Segue abaixo as descrições das politicas.

Antes que vocês me perguntem, podemos fazer alteração nessas politicas? Consigo customizar as politicas já implementadas?

A resposta é NÂO. Nesse caso você é obrigado a seguir essas politicas e avaliar qual enquadra-se melhor dentro de seu contexto de conectividade e controle que deseja executar.

A única exceção que você tem é como anteriormente digitar abaixo quais são os endereços que você deseja que não sejam direcionados para o Umbrella, conforme abaixo.

Peraí, talvez vocês pensem. OK, mas como vou saber o que cada categoria vai filtrar? Boa, mas como o nosso foco não é detalhar as categorias recomendo ver esses detalhes via essa documentação, senão nosso post fica gigantesco. 🙂

Group Policy

Nesta funcionalidade temos os mesmo parâmetros já detalhados para as funcionalidade de ” Firewall & Traffic Shapping “, onde as politicas que precisam ser selecionadas são as mesma já citadas.

Sabemos aqui que o ” Group-Policy ” você irá definir algumas especificações por device o que gostaria de aplicar co-relacionado as funcionalidades Meraki e NÂO de ” Umbrella “.

Logs

Aqui temos mais uma facilidade para que possamos consultar de fato o que está sendo bloqueado pelas nas politicas/categorias implementadas via DNS. Para isso devemos consultar pelo ” Security Center ” que está associado ao Organization -> Security Center.

Vale ressaltar que esse log de fato quando olhamos o request ” http ” ele é feito via ” API “, portanto observe se você esta utilizando algum adblocker, pois isso pode trazer algum erro na consulta do log, ou seja, você precisa avaliar as questões ” cross-site connection “.

Segue abaixo as evidências relacionado aos logs:

Como podem observar os logs ficaram bem simples, onde particamente você visualiza as informações primordiais daquele bloqueio, porém achei que a relação para identificação do SSID que está sendo utilizando não ficou muito familiar e compreensível. Mas vale a dica que o numero que aparece no final está relacionado com a sequencia de SSIDs que temos no portal Meraki.

No meu caso para o teste tinha essa situação:

SSID 0 – RAR -> Security & Moderate Appropriate Use Filtering ( Default )
SSID 2 – Guest -> Security & Full Appropriate Use Filtering

Validação do Funcionamento

Para exemplificar o controle e consolidação das categorias foi feito teste inicial como abaixo para SSID 0.

Neste caso podemos observar que não temos conecitividade como exemplo de uma rede social via SSID 2.

Conclusão

De fato como toda a plataforma Meraki, ela oferece uma facilidade tremenda para colocar esses serviços muito rapidamente em produção, fora que esses ítens correlacionados a segunrança a nivel de camada de DNS, facilita muito em ter apenas um AP e já conseguir oferecer essa granularidade.

Entretanto, o único ponto que acho que acaba ficando conflitante é seguir sempre as mesmas políticas e a estruturação dos logs, onde não traz todas as facilidades investigativas dos alertas.

E vocês o que acharam? Bom? Ruim? Deixe seus comentários abaixo. 🙂

Abs,
Rodrigo

BLOG – Juniper – Treinamentos Free e Vouchers

Thu, 09 Jan 2020 00:00:00 +0000

Olá Pessoal,

Acabei esquecendo e quando fui verificar eu ainda não havia publicado essa informação aqui para vocês sobre os treinamentos Juniper.

Eu posso dizer para vocês que esse programa está ajudando muita gente adquirir conhecimentos básicos e de alguma forma oferecendo oportunidades para os profissionais crescerem em sua carreira, adquirindo certificação e de alguma forma agregando conteúdo técnico para sua carreira.

A Juniper já vem fazendo esse programa acredito há 2 anos ( se eu tiver errado me corrigam ), onde ela esta oferecendo treinamentos online com Voucher Free ( obtendo pontuação mínima no teste online ) para executar 5 provas. Após obter os vouchers é necessário fazer agendamento da prova através do parceiro VUE ( como da Cisco ) e executar sua prova.

As certificações Juniper deste nível, para qual eles estão oferecendo os treinamentos tem uma validade de 3 anos e segue um modelo parecido com o da Cisco. Podemos comparar esse nível de certificação dentro da pirâmide conhecida da Cisco como sendo o nível de CCNA, ou seja, certificações de entrada para qualquer carreira que você deseja seguir dentro do mundo de Juniper.

Eu já obtive duas certificações ( Cloud e Design ) neste programa, e posso atestar que funciona perfeitamento o processo, porém vale lembrar que o treinamento como a prova são feitas em Inglês. Se pensarmos dentro de nosso mundo de TI, isso não deve ser mais novidades.

Também gostaria de adicionar que não somente fazendo o treinamento você irá estar apto para executar a prova, ou seja, vai exigir um esforço para pesquisar sobre o assunto, ler documentações, fazer alguns laboratórios, etc.

Enfim, vamos logo ao que interessa, De fato de tempos em tempos vocês precisam ficar consultando se existem turmas abertas para se inscrever, mas sempre existe alguma delas na lista, portanto se isso está dentro de seu objetivo de conhecimento e crescimentos profissional/pessoal fique atento. Segue abaixo:

- Junos: https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=10175
- Design:https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=10908
- Cloud:https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=10483
- Dev-Ops:https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=11060
- Segurança:https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=11398

Se deseja entender um pouco mais sobre as certificações e torres de tecnologia da Juniper, recomendo observar esse link.

Qualquer dúvida deixe seus comentários.

Abs,
Rodrigo

BLOG – Meraki e Umbrella – SSL + Certificado = Dicas – parte 7

Tue, 05 Nov 2019 00:00:00 +0000

Olá Pessoal,

Resolvi fazer esse post, pois acredito que seja interessante divulgar algumas dicas das que vivenciei fazendo esse pequeno teste em meu ambiente de homelab. Portanto, vou adicionar mais alguns ítens relacionado este parametro dos que já adicionei em nosso post anterior.

Hoje sabemos que a maioria dos sites já utilizam SSL, que por consequencia tem seu certificado instalado no seu website. Esse aumento se deu devido a varias empresas impulsionar essa implementação, por meio de seus programas de utilizar certificado sem a necessidade de pagar por eles, como também sobre a utilização de certificados compartilhados.

Isso deve-se a forma de tentar garantir um pouco de confiabilidade/segurança para navegação na web, porém sabemos que isso é uma ” faca de dois legumes “ rsrs

Não encontrei um número real para passar aqui sobre utilização de SSL, mas um número que circula é que de fato mais de 60% do trafego hoje para acesso as páginas WEB já estão sobre uma estrutura SSL/TLS, na qual quase 37% desso trafego já é utilizado para algum Malware.

Devido a isso, hoje o ” SSL Inspection “ é um ítem importante para que possamos observar algumas anomalias que circulam em suas solicitações. Para que isso essa seja efetivo, o ponto que iremos detalhar é que a ” Cloud Security “, ou seja o Cisco Umbrella irá trabalhar como ” proxy “ e para isso é necessário fazermos a instalação de um certificado ( Root CA ) da Cisco nos clientes para que essas solicitações sejam inspecionadas pelo ” cloud ” e desta forma alguns ataques podem ser bloqueados a nível de solicitações DNS.

Instalação Certificado

Não vou detalhar a instalação, pois a propria documentação já traz vários tópicos que podem ser consolidados neste link, bem como fazer a instalação de diferentes formas em seu ambiente para se tornar escalável.

Porém, vale relembrar que para isso, na criação de nossa politica precisamos habilitar essas funcionalidades e fazer o download de seu certificado.

Como podem visualizar pelo link informado teremos instalações distintas e caso esteja usando o Linux, o que eu fiz foi somente instalar o certificado diretamente pelo browser e caso esteja no Windows esse certificado já fica embarcado no sistema.

Após essa instalação podemos visualizar abaixo que já temos vários ” match “ informado para cada site que ele foi ” Proxied “.

Investigação do Certificado e Validação

Os sites que são classificados pela ” Cloud “ dentro da categoria ” grey list “ serão proxeados, pois eles podem estar direcionando para algum site que está hospedando algum arquivo mal intencionado, porém todo o restante do site é confiável para acesso.

Caso você tenha essa regra habilitada e seu cliente ainda não possui seu certificado instalado, iremos ter a mensagem abaixo e o site não será acessado, pois o navegador acredita que o tráfego está sendo interceptado (e proxied) por um ” main in the middle “, que, neste caso, é o serviço Umbrella, então o tráfego não é descriptografado e inspecionado.

Caso você não queira que um dominio seja inspecionado por alguma caracteristica, você pode colocar em uma lista já definida pelas categorias abaixo:

Inspeção de Arquivos

Baseado que o ” SSL Decryption “ esteja habilitado, podemos ter mais um parâmetro que associado os dois recursos teremos uma credibilidade maior para fazemos analise dos arquivos que são feitos downloads em qualquer website.

Esse recurso irá fazer inspeção dos arquivos maliciosos hospedados em dominios suspeitos, assim no momento que você fizer download um pequeno delay pode ser percebido, já que se esse arquivo está sendo analisado antes de fato ele ser disponibilizado para seu browser.

Para um pequeno teste, existe uma URL que você pode confirmar se de fato você esta com o SSL Decryption habilitado, bem como o ” File Inspection “. Para relembrar e habilitar a inspeção de arquivos você pode conferir em nosso post anterior.

Verifque por essa URL ( http://proxy.opendnstest.com/download/eicar.com ) e a mensagem abaixo precisa aparecer em seu browser.

Após isso você pode consultar pelos relatórios sobre esses eventos e detectar o que de fato foi analisado e bloqueado.

O que vocês acharam dessas informações? Está sendo útil? Gostariam de adicionar maiores explicações, deixe seus comentários.

Para nosso próximo post vou explorar um pouco sobre esse recurso que podemos fazer algumas investigações dentro do dashboard Umbrella. Continue acompanhando!!!

Abs,
Rodrigo

Cisco Meraki – Visualização de Log – Syslog

Mon, 29 Oct 2018 00:00:00 +0000

Olá pessoal,

Voltando a falar mais um pouco sobre Meraki, hoje venho aqui para mostrar novamente mais uma facilidade que pode ser habilitada rapidamente em seu ” Dashboard ” chamado de Syslog.

Não sei se todos já utilizaram o ” Log ” oferecido diretamente pela ferramenta, mas em algumas situações o que é demonstrado não consolida muito baseando no problema que você queira investigar, devido a ter pequenas informações sobre alguns eventos que estão ocorrendo na rede.

Desta forma, temos um protocolo que ajuda-nos não somente neste caso, mas devemos pensar em utilizar em outros casos para obter as informações mais concretas. Vocês podem perguntar, qual protocolo seria? A resposta é o Syslog.

O syslog é um protocolo padrão que trabalha na porta 514 ( TCP/UPD ), com intuito de enviar as notificações ( message logging ) para algum ponto ( destino ) e posteriormente para que você consiga analisar com maior criticidade os alarmes detectados. Devido caracteristica desse produto você pode definir para um host local dentro da sua estrutura ( mais comum ) ou até em algum serviço de cloud, entretanto você irá definir via IP esse serviço que seria o seu destino, no qual ele terá que responder através de um DNS e ao mesmo tempo não devemos esquecer-se sobre a segurança desse serviço por estar sendo carregado através de um ambiente público, ou até mesmo você pode pensar na utilização de cloud mas sendo uma privada ( IaaS ).

Existem outras explicações sobre o protocolo e seu funcionamento, entretanto não vou detalhar neste post, se vocês desejarem posso fazer um post explicando somente o Syslog, para isso deixe seu comentário que planejo o post.

Voltando ao nosso portal Meraki devemos seguir através deste menu Network Wide -> General -> Reporting para habilitar o serviço, conforme figura abaixo:

Vocês podem observar que temos vários filtros que podemos habilitar e vale lembrar que tendo esse serviço habilitado ele irá ” logar ” o inventário que está todo dentro de sua organização na portal Meraki, portanto dependendo de sua estrutura isso pode gerar uma massa muito grande de log se trabalhar com todos esses eventos.

Em nosso exemplo eu habilitei todos para demonstrar para vocês alguns tipos de alarmes, que podem ser validados abaixo:

Neste exemplo temos o inicio do meu log sendo salvo em meu servidor Syslog, posteriormente coloquei uma messagem relacionado a captura da URL que meu dispositivo estava executando e para finalizar apenas uma notificação de Wireless que está relacionado associação de meu dispositivo ao meu SSID. Vale ressaltar que isso está baseado na linha do tempo, correspondendo ao primeiro IP do device que está enviando essa messagem de Syslog.

Em nosso próximo post irei explicar sobre como habilitar o SNMP e os ítens para fazer essa validação.

Espero que vocês tenham gostado da dica. 🙂

Abs,
Rodrigo

Cisco – 4 Free ebooks- Você sabia?

Wed, 17 Oct 2018 00:00:00 +0000

Olá Comunidade,

Como todos vem observando a Cisco já mudou bastante algumas culturas, na qual você já pode pensar/refletir sobre elas. Baseado nisso venho aqui para trazer mais uma facilidade que a Cisco vem trabalhando para conseguir atender uma demanda maior de pessoas, bem como divulgar cada vez mais seus produtos e caminhando para área de Automação, Intuitiva, Programável.

Todo esse progresso está muito relacionado com a cultura agora da empresa de ” Developer ” e com isso atingindo cada vez mais as comunidades e pessoas que buscam essas informações e de alguma forma divulgam elas.

Hoje venho para compartilhar 4 Livros disponibilizados gratuitamente. Ainda não consegui ler todos, pois temos muito conteúdo, porém já estou na metade do livro de IOS XE. Segue abaixo os livros:

Todo esse projeto foi possivel através de uma parceria que iniciou-se em 2014 e que está produzindo os livros com muito menos burocracia e agilidade de editoração e tempo de impressão. A parceira é a BookSprints.

Espero que apreciem a leitura e seja de alguma forma um incentivador para iniciar sua trajetoria nesse segmento.

Abs,
Rodrigo

Ansible – Gerenciando erros na playbook

Wed, 04 Jul 2018 00:00:00 +0000

Olá Pessoal,

Hoje venho aqui para trazer mais um ítem para que possamos agregar em nossas implementações de Ansible, e como vocês vêem observando nós temos algumas alternativas para identificar quando houve um erro com o device, ou de alguma forma que executamos algum erro no módulo que estamos escrevendo por falta de um parâmetro, erro na digitação, caminho da pasta apresentada erronêamente, etc.

Pois bem, nós temos algumas formas de contornar esses alarmes, ou demostrar quais equipamentos estão sendo ignorados, para que possamos continuar com a execução do restante de nossa playbook. Para que possamos iniciar, gostaria primeiramente de apresentar a primeira opção que com certeza vai acontecer, é o fato de termos algum problema no preenchimento da planilha ( .csv ), que por sua vez está atrelado a falta de algum valor em alguma coluna desse arquivo.

Desta forma, para testarmos eu acabei excluindo apenas um valor relacionado à coluna do router R1 e R4, com isso podemos apresentar as metodologias para fazer essa tratativa de erros através de termos que são agregados a sua playbook. A forma que podemos trabalhar é de fato trazendo a função ” ignore_errors “, “ fail ” e ” any_errors_fatal “. Se desejar, recomendo também consultar a documentação do Ansible sobre ” Error handling “.

Abaixo vocês vão observar alteração que fiz no arquivo que popula todas as minhas variáveis do ( .csv ) e abaixo a menção sobre o “ ignore_errors ” classificado como “ yes “.

---
- name: GET VARIABLES FROM CSVFILE
  set_fact:
    vars_dict:
        DHCP: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=1 delimiter=,') }}"
        dhcp_exclude1_start: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=2 delimiter=,') }}"
        dhcp_exclude1_end: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=3 delimiter=,') }}"
        dhcp_network: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=4 delimiter=,') }}"
        dhcp_netmask: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=5 delimiter=,') }}"
        dhcp_gateway: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=6 delimiter=,') }}"
        new_hostname: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=7 delimiter=,') }}"
        id_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=8 delimiter=,') }}"
        ip_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=9 delimiter=,') }}"
        mask_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=10 delimiter=,') }}"
        ip_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=11 delimiter=,') }}"
        mask_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=12 delimiter=,') }}"
        ip_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=13 delimiter=,') }}"
        mask_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=14 delimiter=,') }}"
  with_items: "{{ inventory_hostname }}"
  ignore_errors: yes
  tags:
    - always

Após a inserção desse recurso o que iremos fazer é executar nossa playbook e observar o comportamento na execução do código. Como esperado verifico que o status para os dois roteadores está mostrando como ” ignoring “, ou seja, ele acaba excluindo meu erro e continua execução dos meu outros roteadores, ou melhor dizendo, dos meus hosts já populados em nosso arquivo.\

Se obervamos, vamos analisar os erros posteriores da minha playbook, porque é devido as variavéis que deveriam ter sido capturadas anteriormente, porém sem o recurso de ” ignore_errors ” não vemos a mensagem de “ ignoring “, que por consequência vamos observar na finalização que temos nosso contador demostrando como “ failed=1 ” capturados nessa task ( TEMPLATE 881 ).

Então, para que também seja executado nessa task é necessario adicionar ” ignore_errors ” e agora vamos observar novamente a mensagem e automaticamente temos nosso contador “ failed ” zerado.

Caso você tenha necessidade pode-se usar o recurso de ” any_errors_fatal ” como sendo ” True “, que por sua vez, vai demonstrar o erro e popular em nosso contador.

Talvez vocês estejam pensando em que momento poderia utilizar esses métodos, ou seja, um ítem para pensarmos rápido seria em situações que nossos equipamentos populados no inventário estejam ” unreachable ” que por sua vez vai parar toda execução de sua playbook.

Outro ponto interessante, para que possamos armazenar os logs das execuções de nossa playbook, seria habilitar dentro do arquivo ” ansible.cfg ” um caminho para nossos logs, pois em algumas circunstâncias não vamos estar sempre presentes para analisar naquele momento o erro que ocorreu, ou seja, você vai observar os futuros problemas através desse arquivo.

Para isso devemos editar nosso arquivo e adicionar o caminho através do “ log_path ” conforme pode observar abaixo:

Após isso podemos consultar nosso arquivo populado em nosso diretorio e todas as informações salvas baseado em um timestamp.

Obs.: Nesse parâmetro precisamos ficar esperto com o tamanho desse arquivo se for uma task muito longa e com muitos hosts, bem como para ter um significado maior teríamos que popular “ verbose ” no comando ad-hoc do Ansible.

Bom pessoal, espero que tenham gostado dessas dicas e espero alguns comentários e idéias para compartilharmos.

Abs,
Rodrigo

Ansible – Script baseado na família do equipamento – parte 5

Mon, 02 Jul 2018 00:00:00 +0000

Olá Pessoal,

Já faz um tempo que não adiciono nada em relação a este tema, então vamos trazer mais opções para que vocês possam observar essas idéias e possam adaptar ou criar dentro de seus ambientes que trabalham no dia a dia.

Neste detalhamento vou atrelar aos códigos que já estavamos desenvolvendo nos posts anteriores que trazia o conceito de trabalhar com ( .csv ) e scripts Jinja2, bem como respondendo o que eu havia perguntando no post anterior de nossa série.

Pois bem, nesse primeiro momento vamos fazer a nossa tratativa para selecionar o equipamento através de uma funcionalidade básica, que por sua vez vai depender de alguns parâmetros ” ad-hoc ” no momento de execução de nossa playbook. Eu quis dizer básico, pois vamos adicionar ” tags ” que de alguma forma será identificada manualmente pela inserção do desenvolvedor do código.

Dentro do ambiente Ansible essas ” tags ” são tratadas inerente ao comando ou ação que você esta executando em sua “ task “, ou seja, essas marcações vão ser interpretadas a partir do momento que ela é definida na execução de sua ” playbook “. Portanto, se a ” tag ” estiver identificada aquela task será executada e obviamente se você estiver incluindo “ sub tasks “, “ roles ” as mesmas ações de suas “ tags ” precisam ser identificadas no ambiente. Essa é uma maneira mais rápida e prática identificar as ações que devem ser executadas em sua playbook, porém dependendo de sua demanda outros caminhos e soluções precisam ser analisadas. Para maiores detalhes recomendo observar documentação tags em Ansible.

Na versão 2.4 e 2.5 já temos algumas nomenclaturas adicionadas para que você consiga anexar em sua lógica de execução, e assim facilitar em algumas metodologias. Nesses parâmetros podemos definir ” always “, ” tagged “, “ untagged ” e ” never “. Outro ponto que podemos declarar em algumas situações é através do ” –skip-tags “, na qual eu reforço aqui, que devemos usar através de comandos ” ad-hoc “, como já explicado nesse post sobre esse recurso.

Com isso mapeado, nesse caso vou trazer um exemplo para que possamos gerar scripts distintos para uma plataforma Cisco 881 e outra plataforma Cisco 1941. Venho ressaltar que no script do 1941 estou apenas anexando o nome do router para validação e declarando para identificar que de fato rodamos o template correto via automação. PS.: Esse script não tem muito sentido olhando na visão de router, mas vou testar a lógica.

Primeiramente analisando meu código eu tenho tasks que precisam ser executadas independentemente da plataforma, ou seja, estou utilizando a tag ” always “.

---
- name: JINJA AND CSVFILE
  hosts: all
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml
    tags:
      - always

  - name: LOOKUP IN CSV FILE
    include_role:
      name: lookup_csv_info
    when: ./excel/test.csv is defined
    tags:
      - always

  - name: EXECUTE JINJA2
    include_role:
      name: script_jinja2
    tags:
      - always

Como mencionando preciso adicionar nas minhas “ roles ” que também precisam identicar em que situação iremos rodas essas tarefas. Neste meu caso popular as varíaveis são essenciais, portanto vamos também adicionar a tag ” always “.

---
- name: GET VARIABLES FROM CSVFILE
  set_fact:
    vars_dict:
        DHCP: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=1 delimiter=,') }}"
        dhcp_exclude1_start: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=2 delimiter=,') }}"
        dhcp_exclude1_end: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=3 delimiter=,') }}"
        dhcp_network: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=4 delimiter=,') }}"
        dhcp_netmask: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=5 delimiter=,') }}"
        dhcp_gateway: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=6 delimiter=,') }}"
        new_hostname: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=7 delimiter=,') }}"
        id_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=8 delimiter=,') }}"
        ip_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=9 delimiter=,') }}"
        mask_loopback: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=10 delimiter=,') }}"
        ip_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=11 delimiter=,') }}"
        mask_loopback_x: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=12 delimiter=,') }}"
        ip_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=13 delimiter=,') }}"
        mask_loopback_y: "{{ lookup('csvfile', '{{ inventory_hostname }} file=./excel/test.csv col=14 delimiter=,') }}"
  with_items: "{{ inventory_hostname }}"
  tags:
    - always

Enfim, chegamos no ponto onde vou definir minhas variaveis distintas e obviamente meu template ” script ” distinto. Nesse caso eu criei um arquivo adicional chamado de ” script_1941.j2 ” para emular minha plataforma e avaliar se estou populando corretamente via “ tags “. Após esse detalhamento adicionei mais uma tarefa para separar essas demandas.

---
- name: TEMPLATE 881
  template:
    src: ./template/script.j2
    dest: ./template/configuration/script_{{ inventory_hostname }}.conf
  with_items: "{{ inventory_hostname }}"
  tags:
    - router881

- name: TEMPLATE 1941
  template:
    src: ./template/script_1941.j2
    dest: ./template/configuration/script_{{ inventory_hostname }}.conf
  with_items: "{{ inventory_hostname }}"
  tags:
    - router1941

Agora podemos executar e analisar quais templates estão sendo gerados utilizando via comando ” ad-hoc “. Para isso vamos seguir desta forma chamando como –tags “router1941” .

Agora vamos observar a criação dos templates com suas caracteristicas dessa seleção de “ tag “.

Quando usado por exemplo um –skip-tags “router1941” você pode observar que rodamos outra “ tag “, portanto excluindo toda tarefa relacionada a essa demanda. Se pensarmos, podemos também utilizar a tag ” router881 ” que terá a mesma execução.

Enfim, mais uma vez podemos verificar a diversidade que podemos atender baseando em sua demanda. Em nosso próximo post essa escolha será automatica na qual irei validar no router real que plataforma estamos trabalhando e após isso farei a entrega do template correto ao equipamento. Reforçando que esse códigos estão todos disponivéis no meu Github.

Espero que vocês tenham gostado e falta apenas provar para vocês a questão levantada no post anterior sobre as validações de erros. 😉

Abs,
Rodrigo

Ansible – Loop com Validação de Variáveis – Parte 4

Thu, 26 Apr 2018 00:00:00 +0000

Olá Pessoal,

Esse post acabou surgindo depois de discussões em nosso foruns, mais especificamente no Telegram, onde eu já havia feito essa alteração mas acabei não detalhando em nosso BLOG, sobre essa possível alteração e de que forma poderia ser feito dentro de nossa estrutura de playbook para o Ansible.

Como já mencionado em nossos posts, inúmeras ideias podem surgir baseado na necessidade de seu ambiente e lógicas para cada tipo de configuração, portanto explorar as ideias são sempre bem vindas. Enfim, o que gostaria de agregar aqui nesse post seria sobre uma hipótese de precisarmos fazer uma validação de algum ID de loopback para que possamos amarrar a nossa base externa.

Pensando nesse item e respondendo ao questionamento, é possivel. Com isso iremos fazer atualização em nosso arquivo de teste ( .csv ) definindo variáveis ( x e y ) para popular em nosso exemplo de amarração com loopback ID ( 12 e 13 ).

inventory_hostname,DHCP,dhcp_exclude1_start,dhcp_exclude1_end,dhcp_network,dhcp_netmask,dhcp_gateway,new_hostname,id_loopback,ip_loopback,mask_loopback,ip_loopback_x,mask_loopback_x,ip_loopback_y,mask_loopback_y
R1,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R1_floor1,10,10.10.10.1,255.255.255.255,2.2.2.2,255.255.255.255,
R2,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R2_floor1,10,10.10.10.1,255.255.255.255,3.3.3.3,255.255.255.255,5,5
R3,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R3_floor1,10,10.10.10.1,255.255.255.255,1,2,5.5.5.5,255.255.255.255
R4,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R4_floor1,10,10.10.10.1,255.255.255.255,1,2,5,5
R31,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R31_floor1,10,10.10.10.1,255.255.255.255,1,2,5,5
R32,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R32_floor1,10,10.10.10.1,255.255.255.255,1,2,5,5
R5,false,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R5_floor1,10,10.10.10.1,255.255.255.255,1,2,5,5
R6,true,1.1.1.9,1.1.1.10,1.1.1.8,255.255.255.248,1.1.1.1,R6_floor1,10,10.10.10.1,255.255.255.255,1,1,5.5.5.5,255.255.255.255

Obs.: Vocês podem achar que estou louco

, mas na verdade estou somente jogando valores ficticios nas variaveis definidas como IP Address de loopback, para que possamos de fato validar automação, então não se espante com esses IPs.

Para comparar os IDs ( 12 e 13 ) adicionei eles em nosso arquivo ( /group_vars/all.yml ).

---
vars_from_csv: "{{ vars_dict }}"

cisco_881_l2_interfaces:
  - FastEthernet0
  - FastEthernet1
  - FastEthernet2
  - FastEthernet3

loopback_id:
  - 5
  - 6
  - 7
  - 10
  - 11
  - 12
  - 13

Com isso agora já preparei minha base ( .csv ) e minha variáveis para que agora eu possa montar minha condição obviamente dentro de meu arquivo Jinja2, usando as condições de ” if, elif e else “. Segue alteração de nosso jinja template.

!
{% for loopback in loopback_id %}
{% if loopback == 12 %}
interface loopback {{loopback}}
  ip address {{ vars_from_csv.ip_loopback_x }} {{ vars_from_csv.mask_loopback_x }}
  no shutdown
!
{% elif loopback == 13 %}
interface loopback {{loopback}}
  ip address {{ vars_from_csv.ip_loopback_y }} {{ vars_from_csv.mask_loopback_y }}
  no shutdown
!
{% else %}
interface loopback {{loopback}}
  ip address {{ vars_from_csv.ip_loopback }} {{ vars_from_csv.mask_loopback }}
  no shutdown
!
{% endif %}
{% endfor %}
!

Vocês podem observar que estou criando condições de se coincidir com o ID escrevo isso, caso contrario coincidir com o IDy escrevo aquilo e por fim execute isso.

Dentro desse contexto estou comparando meu ID com o valor quero propagar em meu script e obviamente exportar para meu futuro device. 😉

Agora como desafio e ideias que vocês podem adicionar em nossos comentários, vocês já imaginaram de que forma também eu poderia agregar se eu consolidar o script comparando familias de equipamentos ( 881, 1941, etc ) para após isso montar meu template? E se em meu arquivo de base externa ( .csv ) eu não tiver com uma variável preenchida o que irá acontecer? Posso remediar?

Aguardo os comentários e claro depois de nossas discussões coloco meus exemplos/ideias para esses problemas.

Abs,
Rodrigo

Ansible – Instalar SSH usando processo de automação

Thu, 21 Dec 2017 00:00:00 +0000

Olá Pessoal,

Já faz um bom tempo que não escrevo aqui no BLOG, mas tudo isso é devido outras tarefas que estão tomando também um certo tempo ( recertificação CCIE, estudos DevOps, projetos particulares, aulas, treinamentos, etc ). Enfim, hoje venho aqui trazer uma situação real que acredito que diversos leitores de nosso canal podem vivenciar em sua infra-estrutura e de alguma forma já fizeram esse questionamento quando começei aqui explicar sobre Ansible 💡 . Você pode conferir nossos posts sobre Ansible aqui.

De fato, vocês observaram que a todo momento o que implementamos usando essa ferramenta foi utilizando o processo de acesso remoto a nossos equipamentos, é claro, executando as operações necessarias via CLI. Mas qual é esse acesso remoto? **SSH.

Pois bem, se observarmos todos os módulos para Networking os acessos aos equipamentos é feito pela biblioteca ” Paramiko “, e antes da versão 2.4 do Ansible não tinhamos nenhum módulo para utilizarmos os acessos via Telnet. Devido a isso, foi criado na versão 2.4.0 um módulo para que pudessemos avaliar os equipamentos ou executar algum comando ( CLI ) pelo acesso via Telnet. Esse módulo você pode conferir através desse link ( Telnet no Ansible ).

Baseado nesses fatos, a ideia é acessar os equipamento via telnet, implementar script para habilitar o SSH, e após essa configuração toda a nossa infra-estrutura já estaria apta para utilizar-se de uma metodologia de maior segurança para acesso remoto aos equipamentos e pronto para trabalharmos com qualquer outro módulo disponível dentro da estrutura do Ansible. O que posso dizer é, mais ou menos!!!

Como estamos pensando em automação vamos pontuar os ítens para que isso seja efetivo:

Acessar o equipamento via telnet.
Verificar se o equipamento tem o ssh habilitado.
Qual a versão implementada do SSH.
Caso negativo, devemos instalar o script para acesso via SSH e importar a chave SSH para o host remoto da gerência para evitarmos as perguntas se queremos aceitar a chave em nosso primeiro acesso.
Caso positivo, devemos importar a chave SSH para o host remoto da gerência para evitarmos as perguntas se queremos aceitar a chave em nosso primeiro acesso.

As dificuldades encontradas com o módulo telnet do Ansible é de fato capturar alguns logs ( utilizar pipe ) e fazer as tratativas dos outputs para obter somente o necessário, então o desafio foi encontrar biblioteca para usarmos nesta demanda. Depois de avaliar diferentes caminhos/testes e pedir ajuda à grupo discussão no SLACK Networktocode ( onde indico para todos com intuito adquirir experiências com essas pessoas, e claro, de uma comunidade que de fato ajuda muito nas dúvidas e idéias para desenvolvermos nossas soluções ), verifiquei poderíamos trabalhar com a biblioteca ” ntc-ansible “, pois ela já oferece o acesso via telnet e temos diversos outputs ” show commands ” formatados JSON ” JavaScript Object Notation “, onde a comunidade executou via TextFSM, trazendo assim esse ” array ” para ficar de fato mais pratico a consulta de nossos outputs. Mas, nossa vida não é fácil, pois esse comando que é necessario em minha playbook não tinhamos pronto, porém não foi impactante devido a conseguir executar os filtros e capturar o output essencial do comando.

Para nossa estrutura de arquivos e pastas eu desenvolvi desta forma.

Vocês podem observar que temos uma estrutura de ” roles “, ” templates ” e ” output ” onde a principal pasta para corresponder a nossa playbook estaria dentro de roles, desta forma podemos fazer nossas validações ” conditionals ” na playbook e trabalhar baseado nos outputs/status para as execuções das tarefas posteriores. Nosso arquivo raiz para iniciar implementação estaria em ” ssh_config.yaml “.

---
- name: INSTALL SSH IN CISCO DEVICES
  hosts: routers-client
  gather_facts: no
  connection: local
  vars:
    template_dir: /home/rodrigo/Documents/ansible/ntc-ansible/ntc-templates/templates/

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: INCLUDE SSH ENABLE ROLE
    include_role:
      name: ensure_ssh_enabled

  - name: INCLUDE SSH KEY ON THE PATH .ssh/known_hosts
    include_role:
      name: get_ssh_key

Como podem observar a primeira validação é garantir se temos implementado o SSH, e caso negativo, iremos fazer a implementação de nosso script. Dentro da estrutura de roles podemos ter diversos arquivos denominados com o mesmo nome, porém ele sempre irá buscar o arquivo main.yaml que é a base de nossa role.

---
- name: ACCESS BY TELNET
  ntc_show_command:
      connection: telnet
      platform: cisco_ios
      template_dir: "{{ template_dir }}"
      command: "{{ item }}"
      host: "{{ inventory_hostname }}"
      username: "{{ creds['username'] }}"
      password: "{{ creds['password'] }}"
      secret: "{{ creds['auth_pass'] }}"
  with_items:
      - show ip ssh | include SSH Enabled - version 2
  register: ssh_telnet

- name: ENABLE SSH IF REQUIRED
  include_tasks: enable_ssh.yaml
  when: "ssh_telnet.results.0.response.0 != 'SSH Enabled - version 2.0'"

Para ficar mais claro vocês podem observar no debug ( via ah-hoc command ” -vvv ” ) output sendo demostrado com valor essencial para validar via condição ( when ) de qualquer coisa que seja diferente de versão 2 , então ele irá chamar nossa próxima task para implementar nosso script.

PS.: Nessa execução o valor é o mesmo comparado portando ele esta executando o ” skipping “

Em nossa próxima task temos novamente o acesso sendo executado via telnet e a implementação dos comandos necessário para subirmos o protocolo SSH, liberando assim esse equipamento para seus devidos fins.

---
- name: INSTALL SSH TEMPLATE
  ntc_config_command:
      connection: telnet
      platform: cisco_ios
      host: "{{ inventory_hostname }}"
      username: "{{ creds['username'] }}"
      password: "{{ creds['password'] }}"
      secret: "{{ creds['auth_pass'] }}"
      commands_file: "/home/rodrigo/Documents/ansible/IWAN Project/ssh_installation_by_telnet/template/ssh_configuration.txt"

Após toda essa validação e configuração ( se necessario ) nós precisamos fazer com que nosso host tenha essa chave inserida em seu arquivo de controle ( ~/.ssh/known_hosts ) para que ele não faça essa pergunta chata quando for acessar pela primeira vez seu equipamento.

Para isso, iremos ter nossa próxima role para trazer essas validações e inserções dentro do arquivo necessário. Após chamar role ” get_ssh_key ” iremos novamente ter nosso arquivo main.yaml sendo executado e nele iremos tratar as informações.

---
- name: ACCESS BY TELNET
  ntc_show_command:
      connection: telnet
      platform: cisco_ios
      template_dir: "{{ template_dir }}"
      command: "{{ item }}"
      host: "{{ inventory_hostname }}"
      username: "{{ creds['username'] }}"
      password: "{{ creds['password'] }}"
      secret: "{{ creds['auth_pass'] }}"
  with_items:
      - show ip ssh | begin ^ssh-rsa
  register: ssh_key

- name: Save output in variable related inline command
  set_fact: myvar="{{ ssh_key.results.0.response.0 }}"
  when: ssh_key is defined

- name: Replace space inside myvar
  set_fact:
    clean: "{{ myvar.replace('\n','') }}"
  when: ssh_key is defined

- name: ADD KEY INSIDE LOCALHOST OF SSH CONNECTION
  lineinfile:
    path: ~/.ssh/fake_hosts
    state: present
    line: "{{ inventory_hostname }} {{ clean }}"
    insertafter: EOF
  when: ssh_key is defined

Um dos problemas enfrentados nesse tópico foi justamente a comparação da chave existente com o fato de possívelmente eu já ter essa chave inserida em seu arquivo de hosts, portanto dependendo de sua infra-estrutura essas informações poderiam ficar duplicadas e também a cada execução ele salvar a mesma chave em seu arquivo. Para validação no arquivo temos um módulo muito interessante chamado ” lineinfile ” que de fato ele pesquisa no arquivo se temos essa informação, caso negativo, ele insere o que foi solicitado. Como dito o problema sobre a inserção toda vez que executava a playbook ficava atrelado algum espaço ( \n ) que ele tinha do output ficando interpretável para o modulo lineinfile, com isso precisou ser feito um ” replace ” desses espaços para que pudesse comparar minha variável com o arquivo.

PS.: Vocês vão observar que criei um arquivo ” fake_hosts ” justamente para que você não fique testando dentro de seu arquivo de produção e de alguma forma possa impactar aquilo que esta funcionado, portanto criei o arquivo para você validar os seus passos e analisar se esta sendo executado da maneira correta, pois no momento de rodar talvez em cima de 100, 300 devices o rollback pode ficar complicado. ( rsrs )

Vamos partir do principio que não temos nada instalado em nosso equipamento e a configuração que será implementado é conforme abaixo.

!
username ssh privilege 15 password 0 sshansible
!
ip domain-name cisco.com
!
crypto key generate rsa modulus 2048
!
ip ssh version 2
ip ssh source-interface g3
ip ssh time-out 5
!
line vty 0 4
 login local
 transport input all
!

Abaixo você pode conferir que removi toda a configuração de ssh e deletei no meu arquivo de teste para garantir que não temos nada populado.

Com isso, em nosso próximo output você poderá observar que de fato não consigo fazer nenhum acesso SSH, e após execução de nossa playbook ( capturando duas changes ) temos de fato implementado nosso script e chave inserida. O erro mencionado abaixo em meu detalhamento refere-se ao fato de eu não ter salvo nossa chave SSH no arquivo correto, devido ao que foi comentando logo acima.

Para garantir podemos acessar nosso equipamento e consolidar as informações relacionados ao script implementado, bem como, adicionei um novo usuario.

Validando nosso arquivo ” fake_hosts ” para garantir que temos a mesma chave inserida no arquivo e comparado ao nosso equipamento.\

Vale lembrar que, o foi adicionado em nosso arquivo de ” known_hosts ” é o hostname, portanto se você acessa seus equipamentos pelo nome ele terá essa menção adicionado no arquivo, porém se o DNS não resolver esse nome você terá que acessar pelo endereço IP e que nesse caso não é a mesma informação que populamos em nosso arquivo de “ known_hosts “, sendo assim ele irá questionar para adicionar sua chave.

Logo abaixo, coloco alguns exemplo para garantir o correto funcionamento, colocando hipóteses de alguns itens que podemos obter durante a implementação que diversos hosts.

Nesse caso foi removido apenas ” no ip ssh version 2 ” para que possamos implementar o script, mas não inserir chaves duplicadas em nosso arquivo.

Declaro que esse post ficou bem grande, porém quis demonstrar todas as possibilidades colocando os outputs e anuências que foram vivenciadas até o desenvolvimento dessa automação.

Espero que vocês tenham gostado e de fato ajude de alguma forma a solucionar problemas vivenciados em seu dia a dia. Fique a vontade de compartilhar esse artigo e de colocar mais sugestões ou melhorias para essa estrutura.

Esses códigos estão disponivéis também no meu Github. 😛

Abs,
Rodrigo

Ansible – Validação de Configuração – Parte 3

Mon, 30 Oct 2017 00:00:00 +0000

Olá Pessoal,

Seguindo em nossos posts, continuamos trabalhando para fazer nossas comparações entre as configurações que estão aplicadas em nosso ambiente. Hoje vamos tratar sobre a validação do módulo ” startup-config “.

Como vocês observaram anteriormente, sempre estavamos validando situações onde iríamos comparar arquivos ( scripts ) que poderiam ser aplicados em nossos equipamentos ou validados no sentido de possíveis alterações que de fato não se equipara com nossa base ( backup ).

Logo abaixo, iremos fazer uma validação simples entre “ startup-config ” com a ” running-config “, com isso temos outro motivo para possíveis troubleshooting identificar rapidamente se algo foi alterado, e se de fato essa alteração foi feita da maneira correta, sempre lembrando-se que, essas alterações podem aparecer desde que ainda não foram salvas na NVRAM. Abaixo temos o script:

---
- hosts: all
  connection: local
  gather_facts: no

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: Fill vars
    set_fact:
      provider:
        host: "{{ ansible_host }}"
        username: "{{ creds['username'] }}"
        password: "{{ creds['password'] }}"
        auth_pass: "{{ creds['auth_pass'] }}"

  - name: Compare startup-config with running-config
    ios_config:
      diff_against: startup
      provider: "{{ provider }}"
    register: test_diff

  - name: Take startup-config and sets it to a variable called *before*
    set_fact: before="{{ test_diff['diff']['before'].split('\n')}}"
    when: test_diff['diff'] is defined

  - name: This takes the running_config and sets it to a variable called *after*
    set_fact: after="{{ test_diff['diff']['after'].split('\n')}}"
    when: test_diff['diff'] is defined

  - name: Create a line-to-line diff of running-config to startup_config
    set_fact: difference="{{ after | difference(before) }}"
    when: test_diff['diff'] is defined

  - name: sanitized output "Lines added to running-config that are not present in startup_config"
    debug:
      var: difference
    when: test_diff['diff'] is defined

Vale ressaltar que utilizamos a mesma técnica já explicada anteriormente, onde temos que “ sanitizar ” as diferenças para que de fato tenhamos a saída mais ” clean ” possível, e claro de fácil visualização. No primeiro momento, como vocês vão perceber apenas executei nossa playbook para demonstrar que de fato meu equipamento foi ligado e permanece com a mesma configuração.

A mensangem ” skipping ” é justamente para mencionar que nossa variável esta ” zerada ” e que essa tarefa está sendo pulada para as tarefas seguintes. Segue abaixo:

Agora, como já temos tudo garantido, vamos novamente fazer uma alteração em nosso roteador relacionado a um novo usuário, e claro, não vamos salvar em nossa NVRAM.

Feito isso, agora esperamos que após execução da playbook iremos visualizar que nosso novo usuário foi inserido na ” running-config “. Segue abaixo o output trazendo assim a linha adicional:

Com isso, finalizamos nossas 3 opções de validação de configuração, para qual pode atender diversas opções dentro de nosso ambiente de produção ou mesmo de futuros laboratórios. Pensando assim, vendo nossas demonstrações você avalia que isso de fato pode automatizar algum processo que hoje você precisa executar manualmente ou não consiga gerenciar suas configurações de equipamentos? O que seria mais interessante?

PS.: Vale lembrar novamente que estamos executando somente em um roteador, porém isso, pode ser escalável a muitos equipamentos, apenas alterando nosso arquivo de hosts.

Deixe seus comentários.

Abs,
Rodrigo

Ansible – Rodar um Grupo de seu Inventário

Mon, 21 Aug 2017 00:00:00 +0000

Olá Pessoal,

Detalhando um pouco mais sobre nossa estrutura do Ansible, gostaria de trazer hoje algumas facilidades que podemos executar através de um recurso chamado ” Ad-Hoc commands “, onde caracteriza que podemos passar variáveis, limitar host, executar module, etc, através de nossa própria execução do playbook.

Neste exemplo, o que vou trazer de dica é que, a partir do momento que temos um lista grande hosts ( inventário ) em algum determinado momento acredito que, não queremos obter as informações de todos que estão presentes nesta lista, por isso podemos trazer limitações de quais hosts iremos executar nossas task. Como podem observar abaixo, fiz alteração em nosso arquivo de ( hosts ) adicionando mais equipamentos e trazendo grupos distintos de equipamentos ( routers e switches ). Para maiores detalhes dos comandos ad-hoc veja no site da documentação.

Vale lembrar que, em nossa simulação até o momento não temos esses equipamentos adicionais, foi mais pela questão demonstrar sobre quais os grupos, equipamentos estamos trazendo nesse post.

[routers]
R1 ansible_host=192.168.0.19
R33 ansible_host=192.168.0.21

[switches]
SW1 ansible_host=192.168.0.20

Devido a termos as segmentações de equipamentos fiz alteração em nosso arquivo abaixo, chamando na função ” hosts ” ambos os grupos, mas isso não é um ítem obrigatório, pois iremos chamar nossas funções via parâmetro na execução de nossa playbook.

---
- name: Acesso remoto aos equipamentos
  hosts: routers, switches
  gather_facts: no
  connection: local

  tasks:
  - name: OBTAIN LOGIN CREDENTIALS
    include_vars: secret.yaml

  - name: Define access
    set_fact:
      provider:
        host: "{{ ansible_host }}"
        username: "{{ creds['username'] }}"
        password: "{{ creds['password'] }}"
        auth_pass: "{{ creds['auth_pass'] }}"

  - name: Obtain commands
    include: commands_variance.yaml

Após essa alteração vamos executar nosso playbook, porém iremos adicionar um comando adicional ( –limit “routers” ), que por sua vez irá executar nossas tarefas em todos os routers definidos anteriormente. Segue em detalhe em nosso quadro azul.

Após essa menção detalho que estamos agora chamando nosso próximo grupo.

Logo abaixo faço uma pequena alteração, chamando agora especificamente um hosts que está dentro de um grupo de equipamentos, fazendo com que eu possa executar as tasks sem executar as tarefas em qualquer outro equipamentos que esteja em nossa lista de inventário.

Espero que vocês tenham gostado.

Abs,
Rodrigo

Ansible – Agregar TimeStamp ao Arquivo

Wed, 16 Aug 2017 00:00:00 +0000

Olá Pessoal,

Como vocês estão observando, segue mais uma evolução desenvolvimento para nosso script em Ansible. Acredito que vocês haviam se perguntado: Não vejo nenhum objetivo se eu ficar armazenando/sobrescrever o mesmo arquivo sem ter nenhum histórico ou obter um database de alteração desse arquivo? Pois é, eu também pensei dessa forma, mas devido à isso trago agora uma alteração pequena, porém importante para você rastrear seu histório de alteração ou de logs.

Em nosso playbook podemos utilizar-se da função “ lookup ” atrelado a data+time de nosso sistema operacional que está executando a playbook. Vale ressaltar que essa data não tem nenhuma amarração com o time de seu equipamento ( router, switch, etc ), e sim a máquina host que esta executando nossa biblioteca do ansible, que por consequência devemos garantir para que ela esteja sincronizada com algum serviço de NTP.

Para essa visualização eu fiz alteração apenas em nosso arquivo ” commands_variance.yaml “, adicionando nossa função ” lookup “, e por consequencia adicionei minha varável ao nome do arquivo que estou salvando em ” .txt “

---
  - name: Timestamp
    set_fact: mydate="{{lookup('pipe','date +%Y%m%d_%H%M%S')}}"

  - name: show running-config
    ios_command:
     provider: "{{ provider }}"
     commands:
        - show running-config
    register: config

  - name: save output Running
    copy:
      content: "{{ config.stdout[0] }}"
      dest: "/home/rodrigo/Documents/ansible/{{ inventory_hostname }}_running_{{mydate}}.txt"

  - name: show version
    ios_command:
      provider: "{{ provider }}"
      commands:
        - show version
    register: config

  - name: save output Version
    copy:
      content: "{{ config.stdout[0] }}"
      dest: "/home/rodrigo/Documents/ansible/{{ inventory_hostname }}_version.txt"

Após execução de nossa playbook segue o detalhamento da criação de meu arquivo.

Aguardo comentário e se alguém tiver mais alguma ideia para que possamos manipular esses comandos/arquivos fique a vontade de mencionar ou compartilhar. 😉

Abs,
Rodrigo

Congresso Online 6° Edição – Setembro 2017

Tue, 15 Aug 2017 00:00:00 +0000

Olá Pessoal,

Gostaria de compartilhar com vocês mais um evento que vou participar, para qual já estou nesse projeto desde a 2° Edição, pois é, o tempo passa e já estamos indo para a 6° Edição.

Nessa edição o Congresso está com o tema “ Novos Desafios do Profissional de TI “. Em mais uma edição todo o conteúdo será online, bem como as inscrições são gratuitas.

Esse evento será de 11 a 17 de Setembro, onde para cadastrar-se basta acessar o website do Congresso. Pensando nesse tema escolhi minha palestra como sendo ” Como se manter atualizado na Área de TI “.

Se cadastrem, espero vocês em mais esse evento. Juntos somos melhores!!!

Abs,
Rodrigo

VMware Workstation – Tech Preview

Wed, 19 Jul 2017 00:00:00 +0000

Olá Pessoal,

Foi anunciado pela VMWare o Workstation Tech Preview 2017. O que é isso?

Acredito que todos conhecem esse produto, mas basicamente ele é um hypervisor que é instalado em sua maquina ( Windows, Linux ) e à partir dele podemos criar nossas máquinas virtuais e executar nossos laboratórios ( homelabs ) de diferentes plataformas.

Entretanto, deve também ser de conhecimento de todos que esse programa é pago, ou seja, existe uma licença para que possoamos utiliza-lo. Baseado neste anuncio a VMware esta disponibilizando essa versão para os usuários utilizarem totalmente “ free ” até Dezembro de 2017.

Você pode fazer o download do software e utiliza-lo gratuitamente até Dezembro, lembrando-se que essa versão é um ” beta “, portanto a ideia também é avaliar o software se tem algum ” bug ” e não utiliza-lo em ambientes de produção. Para fazer o download é necessario ter um cadastro básico dentro do portal.

Faça o download do WMware WorkStation. Enjoy it!!!

Atenciosamente,
Rodrigo

Cisco Live Magazine – Edição 21 – 2017

Wed, 28 Jun 2017 00:00:00 +0000

Olá Pessoal,

Segue mais uma edição da revista Cisco Live, na qual temos tópicos para falar sobre Servidores UCS, Telepresence, Setor Educacional com suas implementações em plataformas diferenciadas, etc.

Segue abaixo a edição completa da revista.

Abs,
Rodrigo

Instalação Ansible – Ubuntu

Thu, 11 May 2017 00:00:00 +0000

Olá Pessoal,

Conforme explicado em nosso post anterior, gostaria de trazer algumas dicas para facilitar o seus estudos e que você não ” apanhe ” como aconteceu comigo, perdendo algum tempo para ajustar seu laboratório.

Primeiramente, todo esse ambiente que instalei para praticar meu laboratório estão virtualizados no meu Vmware WorkStation 12, desta forma foi feita instalação do Ubuntu 16.04 LTS ( pode ser feito donwload free do Ubuntu ) através da imagem ” iso ” e iniciado o processo de instalação onde todos os ítens basico do sistema operacional foram instalados. Após finalização do processo de instalação do sistema operacional, você precisa fazer instalação da biblioteca Ansible em seu SO e obviamente capturar a versão mais nova do Ansible + Python. Segue abaixo os comandos em Ubuntu para instalação:

$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt-get update
$ sudo apt-get install ansible

Após essa instalação vocês devem observar que foram instalados todos os pacotes do Ansible, mais as bibliotecas do Python que o proprio Ansible utiliza-se para execução de suas tarefas. Para garantir integridade de instalação você pode conferir através do comando abaixo:

root@ubuntu:/home/rodrigo# ansible –version

( Status de instalação na minha máquina ):

root@ubuntu:/home/rodrigo# ansible –version
ansible 2.3.0.0
config file = /etc/ansible/ansible.cfg
configured module search path = Default w/o overrides
python version = 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609]

Como padrão do SO ele vai instalar toda essa demanda na pasta ( /etc/ansible ) e como dica eu recomendo que você copiei o conteúdo dessa pasta e grave esses arquivos em uma outra pasta ( /documents ) para que você possa trabalhar tranquilamente com esses arquivos, sem impactar na sua instalação, já que estamos apenas praticando nossos conceitos e erros de fato podem acontecer.

Agora temos nossa biblioteca/app instalado e podemos começar a trabalhar em nossos scripts. Mas, aqui dou mais uma dica para facilitar para você que irá começar a escrever seus scripts, e que não sofrá com a ” syntax ” da linguagem de programação, que por usa vez, podem trazer diversos erros que são muitas vezes indecifravéis, para nos que estamos iniciando nessa área.

Claro, que as pessoas que já estão acostumados a trabalhar com essas ferramentas podem continuar da mesma forma, mas aqui vou partir do principio que nem todos fazem isso em seu dia a dia, então para que você não fique ” stressado 👿 ” com as teclas de atalho que o ” vi ” traz para você e obviamente ele não traz uma ” syntax ” amigável, eu recomendaria a instalação do Atom.io que irá facilitar muito nossa vida tanto em programação de Python como em Ansible. Existem diversas ferramentas para esse tipo de trabalho, portanto fiquem a vontade de utilizar a que mais adequa-se a você. Para instalação do Atom você pode executar conforme abaixo:

sudo add-apt-repository ppa:webupd8team/atom -y

sudo apt-get update

sudo apt-get install atom -y

Após instalação do Atom eu recomendo que você inicie o aplicativo de edição sempre em modo ” root “, para que desta forma você já posso compilar, validar e grava através de seu editor de texto, diminuindo assim algumas tarefas para execução de seu playbook ansible. Para isso basta iniciar a aplicação como abaixo:

sudo atom

Após inicialização você irá visualizar sua tela de edição conforme figura abaixo:

Em nosso próximo post vou trazer mais alguns caminhos para que você possa instalar em seu ” editor de scripts ” para que possamos ter algumas validações de syntax para o Ansible.

Abs,
Rodrigo

Cisco DNA – Enterprise NFV

Fri, 10 Mar 2017 00:00:00 +0000

Olá Pessoal,

Conforme mencionado anteriormente, gostaria de trazer mais alguns itens co-relacionados a estrutura Cisco DNA, com uma maior visibilidade dentro do ambientes de nossos clientes ( Branch Sites ) com as novas estruturas de NFV ( Network Function Virtualization ).

Devido anuncio desse novo hardware e as tendências de mercado trago hoje mais algumas nomenclaturas e recursos que podemos oferecer utilizando equipamentos Cisco. Para isso mostro abaixo os componentes que estão integrando-se para um solução NFV.

Dentro dessa estrutura podemos visualizar algumas camadas:

Orquestração: Sendo executada pelo APIC-EM bem como o ESA, que são ferramentas de configuração de equipamento, gerenciamento de todas as caixas em seu ambiente de produção
Serviços de Rede: Nesse tópico o grande ponto seriam ” conectadores ” com outros fabricantes através de APIs ou até mesmo de ” VMs ” que poderiam ser instaladas ofertando um serviço de Firewall, Otimização de WAN, etc.
NFVIS: Seria a camada de abstração para que suas plataformas de VNF possam trabalhar, baseando em um Kernel para seu equipamento. Podemos fazer uma analogia por exemplo com um ESXI, Hyper-V, KVM. Neste item recomendo uma leitura relacionado ao NFVIS.
Plataforma ( Hardware ): Neste item seria abordagem que podemos fazer baseando-se em um UCS, ENCS e até de um roteador 4K.

Baseando-se nesses itens gostaria dar uma visibilidade dos possíveis hardwares que podemos pensar quando falamos em NFV.

Agora como você visualiza um item conhecido ” roteador “, gostaria de trazer ideias para que você possa pensar no momento quando é mencionado ” O roteador que está no meu cliente hoje não terá mais funções? “. O que posso responder para você seria ” tudo depende “. 🙂

Porque? Porque, avaliações precisam ser feitas com a intenção de entender o fator de crescimentos e as necessidades exigidas para seu crescimento. Hoje na plataforma 4K, temos hardware ( UCS ) que pode ser inserido, para que baseando-se nos limites desse hardware muitos serviços de NFV podem ser ofertados, bem como, instalações de Sistemas operacionais nesses equipamentos. Esse hardware pode potencializar seu equipamento oferecendo muitos serviços de virtualização.

Baseando-se nessas informações o que visualiza dessas novas soluções? Podem trazer benefícios para nosso dia a dia?

Abs,

Rodrigo

Cisco DNA – Digital Network Architecture

Thu, 23 Feb 2017 00:00:00 +0000

Olá Pessoal,

Gostaria de trazer uma novidade sobre anúncio de um novo produto que a Cisco esta trazendo para essa categoria de SD-WAN, SDN, Digital Network.

Os produtos, que incluem um dispositivo em um site remoto onde temos NFV ( Virtualização de Funções de Rede ) trazendo melhorias para o software segmentação de redes, estão sob o plano de arquitetura de Rede Digital da Cisco. DNA oferece software integrado de rede – virtualização, automação, análise, gerenciamento de serviços em nuvem e segurança em uma única plataforma.

No lado do hardware, a Cisco lançou o Enterprise Network Compute System (ENCS) Série 5400, um servidor 1RU Intel Xeon que inclui 8 portas GE onde suporta LTE, T1, DSL, bem como Dual-Phy Gigabit Ethernet WAN e 64Gb de memória.

O 5400 é uma plataforma para sites remotos criados para ajudar os clientes a acelerar suas implantações Enterprise NFV estendendo roteamento, segurança, otimização de WAN e outros serviços de rede para seus ambientes de filiais.

Para você entender um pouco melhor arquitetura segue a foto de um slide relacionado apresentação do produto.

Em nossos próximos post vou explicar um pouco melhor sobre esse termo que a Cisco está trazendo como DNA. Para que vocês possam entender um pouco melhor segue o link sobre Cisco DNA.

Abs,
Rodrigo

API – DevNet

Thu, 16 Feb 2017 00:00:00 +0000

Olá Pessoal,

Acredito que você tenha lido nosso post anterior sobre API e conforme informado vou trazer alguns ítens que venho acompanhando nessa área que estamos trabalhando ( Routing & Switching e DC ).

Como venho falando em alguns posts anteriores nossa área está alterando-se e devido a isso muitas movimentações estão acontecendo nas organizações para se adequar as novas tendências bem como re-estruturar seus produtos para que os concorrentes não atropelem e definitivamente as marcas não caiam no desuso.

Acredito que vocês souberam da última aquisição da Cisco de uma empresa chamada “ APPDynamics “, pois bem, se observarmos é mais uma empresa tendo seu core business para aplicações. Além disso, podemos observar as ultimas aquisições da Cisco pelo link ( Cisco Acquisition ).

Olhando neste cenário de aquisições da Cisco, qual é a maioria do core business dessas empresas compradas pela Cisco? Se você pensou empresas de software, está correto.

Devido essas novas demandas que estão surgindo exponencialmente, ela como uma gigante não pode ficar esperando ( porém eu achei que ela demorou para acreditar nisso ) que outros fabricantes roubem muito seu mercado, desta forma hoje eles já tem times especificos e uma grande comunidade que está desenvolvendo para que os equipamentos, com sua APIs sejam utilizadas por qualquer desenvolvedor ou fabricante.

Como podem observar pela foto acima Cisco esta trazendo essa menção chamada DevNet, onde já temos o site Developers Cisco, que traz diversas informações relacionados aos desenvolvimento de cada plataforma. Para cada plataforma nós já podemos consultar as APIs publicas baseando-se em cada torre de tecnologia ( Cloud, Networking, Datacenter, etc ).

Se vocês navegarem pelo site, podemos mencionar ainda que não temos muitos ítens disponibilizados para executar as tarefas, mas com certeza eu acredito que isso vai crescer exponencialmente. Vocês acham que isso pode crescer?

Em nosso proximo post vou mencionar um pouco mais sobre o SandBox

Abs,
Rodrigo

O que é API e Rest API?

Mon, 13 Feb 2017 00:00:00 +0000

Olá Pessoal,

Devido as novas demandas que estão surgindo, principalmente a relação de integração de software com nossa infraestrutura ( routers, switches, firewalls ) esses termos mencionados em nosso título acabam sendo evidenciados.

Acredito que todos quando observam esses termos imaginam que isso seja algo relacionado a quem trabalha com programação, integração de sistemas, desenvolvedores de sistemas, etc.

Pois bem, isso não é mais a realidade que vivenciamos em nossa área de redes e infraestrutura. Porquê? 💡

Como todos nos sabemos nossa área esta passando por várias transformações, bem como as empresas estão adicionando em seus produtos muitas funcionalidades que podem ser visualizadas / consultadas por outros fabricantes, com o intuito de oferecer serviços e integrações entre as plataformas. Com isso podemos definir dois ítens:

API ( Application Programming Interface ) : Isso está relacionado a ferramenta ou biblioteca que pode ajudar aos desenvolvedores acessarem informações dentro de seu código ( fabricante ) para fazer a tratativa das informações necessária para o desenvolvimento de sua ferramenta. Essas APIs podem estar contidas nos sistemas operacionais, sistema de banco de dados, hardware de computadores, etc. No caso de uma API podemos mencionar que pensando no protocolo HTTP você poderia fazer um ” GET ” no código para obter as informações.

Como exemplo de uma API poderíamos citar dois exemplos:

Quando acessamos um site onde vamos pesquisar seu endereço e nele temos o mapa do ” Google MAPS ” populados automaticamente na página daquele cliente, e da mesma forma podemos navegar nessa janela olhando pelas ruas próximas ao mapa, ou seja, o site está acessando uma API publica do Google para mostrar aquela informação.
Poderíamos citar sobre o Facebook que disponibiliza uma API para que por exemplo outros software possam fazer uma publicação automatica baseado na sua autorização de utilização da API ( Keys ).

Rest API ( Representational state transfer API ) : Como informado acima API oferece caminhos para que você possa acessar as informações, e quando a menção se torna uma REST API seria quando eu defino funções a qual os desenvolvedores podem executar solicitações e receber respostas por exemplo através do protocolo HTTP ( GET e POST )

Com isso diversas plataforma agora estão vindo com API públicas para que você possa consultar e de alguma forma possa interagir com as ferramentas / hardware que esse fabricante disponibiliza. Você poderia estar pensando o que vou fazer com essas funcionalidades?

Em nosso segundo post vou mencionar sobre o que fazer com essas funcionalidades e como a Cisco está trabalhando com essas novas demandas.

Abs,
Rodrigo

Atualização nos valores de prova da Cisco

Thu, 09 Feb 2017 00:00:00 +0000

Olá Pessoal,

Acredito que para muitos isso não será uma noticia boa, pois hoje foi anunciado pela Cisco os novos valores das provas que estão sendo cobrados a partir de hoje ( 09/02/2017 ).

Para a maioria dos ” tracks ” tivemos uma atualização em torno de U$50,00, ou seja, é mais um motivo para que todos se dediquem cada vez mais nos estudos, para que você consiga alcançar sua certificação em sua primeira tentativa, com isso seu ” bolso ” não sofrerá tanto impacto.

Como evidência para que vocês vejam:


Certification	Preço antigo ( U$ )	Preço Novo ( U$ )
CCNA R&S	295,00	325,00
CCNA Security	250,00	300,00
CCNP	250,00	300,00
CCIE Written	400,00	450,00

Para consulta de outras certificações verifique no site da VUE – Certificação Cisco.

Dentro desse parâmetro vocês imaginavam que os valores iriam subir? O que acharam desse aumento? Deixe seus comentários. 😉

Abs,
Rodrigo

Cisco Champion 2017

Tue, 07 Feb 2017 00:00:00 +0000

Olá Pessoal,

Eu recebi essa noticía na última sexta-feira, mas devido a correria estou escrevendo apenas hoje. Vocês já devem estar percebendo que foi incluido em nosso tema um ” badge ” relacionado Cisco Champion 2017. Nossa o que é isso?

Basicamente é um programa que a Cisco promove todo ano ao seus contribuidores, que difundem as idéias e compartilha de um modo geral para as comunidades seus conhecimentos e ideias das mais atuais ferramentas e tecnologia, oferecendo assim seu tempo para que todos possam crescer junto em nossa comunidade.

Para que você possa entender um pouco mais sobre o programa acesse o CiscoChampion site, onde suas perguntas podem esclarecer-se um pouco mais na aba FAQ.

Enfim, depois de tudo isso tenho a imensa novidade de anunciar que esse ano eu fui escolhido para ser um integrante desse time, e assim desfrutar de alguns pontos interessantes que temos no programa. Com certeza, essa conquista não é feita de apenas um integrante, mas sim de todos vocês que de alguma forma contribui para que eu possa continuar escrevendo e repassando o conhecimento que venho adquirindo durante toda a minha carreira.

Desta forma fico muito orgulhoso e espero representar bem vocês nessa conquista. #CiscoChampion

Logo abaixo vocês podem acompanhar no twitter a hash tag.

#CiscoChampion Tweets\

Abs,
Rodrigo

Desafio 11

Sun, 11 Nov 2012 00:00:00 +0000

Olá Pessoal,

Segue mais um desafio.

Desafio 11

Qual das seguintes afirmações melhor descreve as características de transmissão das redes abaixo, observando em questões de domínios de colisão e domínio de broadcast? (Seleccione as duas melhores resposta)

A – Há dois domínios de broadcast na rede.
B – Existem quatro domínios de broadcast na rede.
C – Existem seis domínios de broadcast na rede.
D – Existem quatro domínios de colisão na rede.
E – Existem cinco domínios de colisão na rede.
F – Existem sete domínios de colisão na rede.

Participem!!!

Abs,
Rodrigo

Redes on Cisco Redes

BLOG – Cisco Meraki – Radius em Cloud

Radius no Meraki

Configuração no Meraki

Configuração no JumpCloud

Autenticação no WI-FI

Logs

Conclusão

BLOG – Podcast Cisco Champion – Small Business – Big Value

BLOG – O que é ping? Protocolo ICMP?

O que é o ping?

Qual protocolo é utilizado?

O ICMP é uma aplicação?

O ping é uma aplicação?

Mensagens ICMP

ICMPv6 – Julga-se para o IPv6

Resumo

Resumo do BLOG – Referência 2020

Conquistas

Certificações

Conclusão

Meraki – Adicionar Aplicação Meraki Insight – Parte 4

Configuração

Resultado

Conclusão

Segurança – Exploração de Protocolos Autenticação – Dicas – Parte 3

Metodologias

Proteção

Residencial

Corporativo

Conclusão

Meraki – Analisar Gráficos Meraki Insight – Parte 3

Detalhamento

Visualização da Organização

Consolidação da LAN

Consolidação da WAN

Consolidação da Aplicação

Conclusão

Segurança – Entendimento dos Pacotes na Rede WIFI – Parte 2

Autenticação

Associação

De-Authentication

Beacon

EAPOL ( Extensible Authentication Protocol Over LAN )

Conclusão

Meraki – Iniciar o serviço para analise do Meraki Insight – parte 2

Habilitar o serviço

Validação dos dados

Web Health

Conclusão

Segurança – Analise de WIFI – Entendimento via Air-Crack

Instalação

Funcionalidades

Inicialização dos comandos

E agora?

Conclusão

BLOG – Primeiro post sobre Python

Projeto

SpeedTest

Lab

Código

Dashboard

Conclusão

BLOG – Cisco Meraki – Wireless Health – O que é?

Wireless Health

Exercendo consulta através do AP

Device mais impactado

Estatisticas menu Wireless -> Wireless Health

Visualização Latência

Logs

Conclusão

BLOG – Cisco Meraki – MR Per Device License + Umbrella

Licenciamento

Per Device license

Configuração inicial

Firewall Traffic Shapping

Group Policy

Logs

Validação do Funcionamento

Conclusão