Tutorial on Cisco Redes

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

BLOG – IP Fabric – Gerar Relatório – parte 7

Mon, 11 May 2020 00:00:00 +0000

Olá Pessoal,

Após algum tempo venho trazer mais informações sobre nossa ferramenta de gerência e inventário que venho detalhando para vocês. Em nosso último post trouxe detalhes sobre a nova atualização que temos para trabalhar com as famosas API da Meraki.

Como podem ter observado em nosso título, hoje venho trazer outro ítem que achei bem interessante, pois de alguma forma já temos algo automatizado que podemos entregar em questões de segundos para um nível superior dentro de nossas organização, bem como para outras áreas que tenham interesse para identificar o que de fato temos em nossa rede, bem como alguns problemas que estão sendo evidenciados.

Como gerar os relatórios

A melhor forma demonstrar isso são através de relatório, no qual você vai trazer algo bonito e detalhado, agregado aos números. Pensando desta forma, vamos seguir para demonstrar como obter esse relatório.

Inicialmente precisamos observar em Report -> Network Analysis Report

Após esse procedimento você já pode observar todos os relatórios disponíveis para fazer download. Lembrando que esses relatórios de fato vão estar relacionado com o discovery que você executou em sua infra-estrutura, bem como atrelado com os ” database “ associados a sua base.

Após esse procedimento já podemos observar que nosso documento já estará disponível para utilizarmos.

Agora capturei algumas telas desse relatório apenas para você verificar alguns dados que de fato estão sendo importados para esse documento, e o que você terá para apresentar para seu chefe.

Uma base de dados sobre a quantidade de endereços que você tem em sua infra-estrutura ( Network Total, IP Address, DNS, MAC, etc )

Logo abaixo capturei um dado interessante que demonstra para você quais devices eu tenho naquele momento ” duplex mismatch “.

Neste exemplo abaixo a saúde de sua rede baseado no protocolo OSPF, bem como exportando isso para uma tabela dando uma visibilidade muito rápida onde possíveis problemas podem estar acontecendo devido ao tempo que essa sessão está operacional. Isso já pode ser números para que você possa atacar os problemas mais criticos e trabalhar em um planejamento para resolver esses problemas.

Mais uma informação relacionado a outro protocolo ( BGP ), que rapidamente já temos dados efetivos de toda a nossa infra e avaliar ” Porque temos tantas sessões Active? “, ” Será que estamos fazendo desativações corretas ou temos problemas maiores na rede? “. Enfim, alguns ítens que podemos pensar e agir de forma rápida.

Enfim, temos diversas informações adicionais no relatório que podem ser utilizada por diferentes áreas e consolidar o que de fato é relevante para ações imediatas.

Conclusão

No meu ponto de vista, por se algo muito prático e rápido para captura do relatório é muito vantajoso, pois podemos entregar algo para diferentes áreas que podem trabalhar nas identificações especificas de cada problema detectado.

Um problema que avalio é que de fato o relatorio somente é gerado em Inglês, o que pode impactar para alguns setores a nível Brasil, porém pode ser algo que poderia ser trabalhado junto ao ” vendor “, mas hoje nosso mundo de TI na maioria das vezes por padrão os documentos já devem ser entregue em Inglês.

Espero que vocês tenham gostado de mais essa dica.

Abs,
Rodrigo

BLOG – IP Fabric – Vendor API Meraki – parte 6

Wed, 15 Apr 2020 00:00:00 +0000

Olá Pessoal,

Acredito que todos vem acompanhando os posts que estou relatando sobre essa nova ferramenta que estou testando e avaliando o quanto é interessante para nossas estruturas.

Pois bem, recentemente tivemos atualização para versão 3.5, e como as solicitações estavam sendo demandadas, temos uma nova funcionalidade que é fazer mapeamento de estruturas Meraki. Ohhh!!!

Talvez vocês já estão se perguntando e pensando varios ítens:

- Porque vou utilizar outra ferramenta para inventário?
  > Eu já tenho tudo no dashboard Meraki sobre as informações de equipamento, serial number, licenças, topologia. Esse Rodrigo está doido!
- Porque ter outra ferramenta para eu cuidar, já que tenho tudo no portal Meraki?
  > Vou ter mais trabalho para ficar gerenciando meu ambiente e mais informações perdidas entre as ferramentas. Esse Rodrigo está doido!
- No portal Meraki eu consigo gerar relatório automaticamente, porque usar outra ferramenta?
  > Posso obter todos os dados automaticamente no dashboard. Esse Rodrigo está doido!
- A topologia é completa no portal Meraki?
  > Sim. Esse Rodrigo é doido!

Enfim, talvez aqui poderíamos ter mais questionamentos, e vocês podem ainda estar viajando em outros tópicos. Porém, se você já leu os outros posts e você acredita que posso ainda trazer valor para suas idéias, não me deixe sozinho, acompanhe comigo meu raciocínio.

Configuração API

Para que possamos trabalhar com essa funcionalidade no IP Fabric, é necessario que executamos todo o procedimento através de APIs, ou seja, nossa ferramenta vai buscar todas as informações através das APIs já divulgadas pela Meraki.

Portanto, recomendo vocês pesquisarem em nosso BLOG os posts de Meraki ( temos vários..rsrs ), porém o mais importante para esse momento seria ” Facilidades Através de APIs – Meraki ” que obrigatoriamente você precisa ter esses dados para inserir em nossa ferramenta de gerência – IP Fabric.

Para isso outro dado importante é que você atualize IP Fabric para versão 3.5. Se tiver dúvidas como executar, recomendo ler esse post.

Pois bem, depois de ter essas validações precisamos iniciar o processo de cadastro, que deve seguir através Settings -> Advanced -> Vendors API. Confira abaixo:

Logo abaixo você pode conferir quais dados são necessários preencher para seguir nosso processo.

Como todos sabem o processo de acesso API Meraki é executado via Internet, portanto tenha consciência que sua ferramenta de gerência precisar obrigatoriamente alcançar Internet para consolidar consulta da APIs Meraki, correspodendo ao seu dashboard e organização.

Após esse processo verifique que nosso vendor foi adicionado com sucesso. 🙂

Processo Descoberta no IP Fabric

Após esse procedimento podemos executar nosso discovery e avaliar quais os dados que serão capturados. Verifique abaixo que nosso gráfico ja começou a processar as informações e obter os dados.

Como minha estrutura para teste é pequena, já observamos que meus dois equipamentos já foram populados.

Consolidação dos dados

Para isso, já posso validar o que de fato ele populou em nosso inventário relacionado ao meu MX.

Todos os equipamentos iremos observar um campo denominado ” CLI output “, que por sua vez iremos fazer o download de um arquivo conforme abaixo.

Neste documento basicamente o que teremos são as APIs que o IP Fabric consultou dentro de sua organização/equipamento para obter esse dados que foram populados. Isso acaba sendo interessante para avaliar o procedimento que esta sendo validado e as URIs ( Uniform Resource Identifier ) que estão sendo processadas.

Após esse processo fui validar algum ítem para avaliar as conectividades e acabei apenas pegando algo para filtar sobre ” LLDP ” e já podemos verificar que temos os dados mapeados de portas e suas funcionalidades.

E por último fui consolidar se poderíamos também ter um item interessante que é a validação do trafego dentro de nossa estrutura. Após popular um trace, posso observar que de fato ele traz meu trafego baseado em minha infra-estrutura, o qual eu vejo muito interesse nessa consolidação que é feita por varios dados ( MAC, ARP, Roteamento )

Conclusão

Vocês conseguiram perceber algo que podemos agregar nesse ambiente? Se sim, ufa acho que consegui transmitir a informação correta.

Se não, acredito que eu não tenha colocado as informações corretas ou de fato você caiu de paraquedas neste post, pois a utilização da ferramenta é trazer para você um ” baseline ” e após esse procedimento você tenha consolidações para executar através de diversas bases de dados e avaliar o que está ocorrendo em sua estrutura, o que foi alterado, quais problemas estão sendo vivenciados ( roteamento, mismatch portas, etc ).

Obviamente um ítem para pensar aqui, é que esse é primeiro release para trabalhar com APIs nessa ferramenta e pensando em Meraki, sinto falta pela descrição se teremos todas as validações para um ambiente SDWAN. O jeito é aguardar as proximas ” release ” ou consolidar se tem roadmaps. 🙂

E por fim vem o questionamento. O Rodrigo esta doido?

Espero que tenha gostado.

Abs,
Rodrigo

BLOG – IP Fabric – Topologia Completa Client A – parte 5

Tue, 24 Mar 2020 00:00:00 +0000

Olá Pessoal,

Depois de ter mostrado para vocês nossa estrutura relacionado a nossa ferramenta IP Fabric, hoje estamos aqui para trazer mais dados, com isso demonstrar de fato toda a topologia mapeada.

Vale lembrar que em nosso ultimo post, mostramos nossa topologia e o nosso primeiro ” discovery “ relacionado unicamente ao nosso site denominado Datacenter.

Comparativo de LOGs

Inicialmente aqui temos um comparativo que levantei apenas colocando em produção minha sessão BGP com um snapshot que não havia colocado em operação. As linhas vermelhas declaram para esse caso que no backup anterior isso não existia.

Se obtiver uma base mais antiga, que foi quando demonstrei em nosso post anterior sobre a varredura somente de nosso DC, desta forma podemos ver que não existia nada.

Para reforço as cores que estão em vermelho é de fato a estrutura que não existia e não temos nada relacionado ao protocolo, pois havia selecionado somente parte física.

Inventário

Como em todo ambiente que trabalhamos o inventário sempre é importante, pois à partir dele iremos conseguir analisar o que de fato temos na rede, com isso obter alguns dados mais interessantes.

Segue abaixo um ” snapshot “ selecionando Inventory -> Devices, após isso iremos obter diversas informações de cada equipamento que foi mapeado pela ferramenta. Desta forma temos hostname, IP Gerenciamento, Versão IOS, etc.

Obviamente você vai conseguir fazer seu inventário correto se de fato você tem esse equipamento alcançavel pela gerência e seus usuários cadastrados posso executar comandos de nível 1.

Você já pensou em obter part number automático? Se sim, neste exemplo podemos obter dados interessantes como modelos de SFP, part numbers das placas instaladas, etc.

Entretanto para nosso ambiente virtualizado alguns valores acabam sendo irrelevantes, pois não traz dados reais como se fosse um hardware físico.

E aquela situação que você vai consolidar se a porta ficou em auto/duplex forçado ou automático? Pois bem, logo abaixo você pode visualizar rapidamente e avaliar se é interessante trabalhar nestes parâmetros para fixar algum problema de mismatch, bem como se você está verificando em algum log que existe MAC duplicado, poderá fazer um filtro rápido e avaliar qual é o equipamento.

Inventário pela tecnologia

Pois bem, e agora se eu quiser pesquisar alguns equipamentos e avaliar o que de fato temos baseando-se inicialmente por VLANs dentro das estruturas de LAN e consolidar se estão ativas ou não. Verifique abaixo via Tecnology -> VLANs.

Desta forma ainda temos varias possibilidades de trabalhar relacionando a tecnologia, no sentido de avaliar de fato se podemos ter alguma adjacência de BGP em estado de alerta ( active, opensent, openconfirm, idle, connect ).

Questões sobre Roteamento

Enfim, chegamos em mais um ítem que acho bem interessante que seria trazer visibilidades sobre Topologia completa mapeada por Conectividade Física + Protocolo Layer 2 + Roteamento.

Desta forma, podemos visualizar abaixo a topologia montada e que pode ser utilizada como sua fonte de consulta para futuras consolidações e até validações de ” changes “ não documentadas em seu ambiente.

Nesta topologia você pode arrastar os equipamentos e organizar da melhor forma para verificar as conectividades e após isso salvar o desenho caso queira ter em algum repositório.

E como poderíamos consolidar qual é caminho, equipamentos, assimetria, RPF ( Reverse Path Foward ) temos em nosso ambiente? Vocês podem conferir abaixo.

Neste exemplo estou executando ” traceroute “ de um end-point para outro denominado em um site distinto, assim já podemos ver rapidamente todo o trajeto basedo em varias informações que já foram capturadas dos equipamentos. Lembrando-se que aqui está somente selecionado para checar assimetria, ou seja, as linhas verdes me declaram que eu tenho os caminhos sendo idênticos do ponto A para B e do B para A.

Conclusão

Tenho que declarar que de fato, depois que as informações foram carregadas e as bases de dados já estão populadas, essas consultas se tornam muito rápidas e concisas, pois não precisamos entrar em vários equipamentos para consolidar as informações, bem como você pode obter uma ” baseline “ da sua rede funcional e comparar com os eventos que ocorrem para identificar algumas ações.

O que vocês acharam? Gostaria de verificar alguma informação especifica? Deixe seu comentário, pois pretendo fazer um video e assim posso cobrir alguns tópicos.

Abs,
Rodrigo

BLOG – IP Fabric – Primeiro Discovery – Parte 4

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

Olá Pessoal,

Conforme prometido estamos aqui para seguirmos com nosso detalhamento sobre a implementação do IP Fabric. Se você não acompanhou os posts anteriores eu recomendo visualizar eles através desse link, assim você acaba entendendo todo o processo e o propósito dessa ferramenta.

Topologia

Para que todos possam entender melhor eu montei uma topologia no EVE-NG com o intuito de testar a ferramenta e avaliar quais os dados são capturados e como eles são trabalhados pela ferramenta.

Segue nossa topologia inicial.

O proposito inicial nessa topologia é tentar criar alguns protocolos e tipos de topologia diferenciado para que possamos ver o que de fato é populado para nós a partir do momento que começamos a fazer a varredura em nossa rede.

Nesse contexto temos as nomenclaturas populadas em cada ambiente, porém segue abaixo a resumo:

**– Backbone MPLS:**Contém PEs, Ps, RR todos definidos através do AS333

– Client A: Inicialmente definido um DC e posteriormente vamos crescer com tipos de sites remotos distintos, utilizando a estrutura compartilhada do backbone mencionado acima.

– Client B: Sites com conectividade ao ambiente backbone, porém apartados via VRFs distintas e com topologias inicias básicas.

Como proposito do DC ( Data Center ) foi colocar a ferramenta nesse ambiente, não é uma topologia ideal pensando que você irá monitorar um cliente diferente, porém devido a recurso (MEM, Proc nohome lab ) eu não quis colocar uma ferramenta também no Client B e também não coloquei no Backbone ( para emular como um prestador de serviço monitorando as pontas ), pois ficaria sem visualizar algo que vamos crescer para protocolos Layer 2 no DC.

Enfim, novamente como mencionando isso é uma ideia inicial e que pode crescer para avaliar, porém vale o exercicio inicial para ver se de fato vale a pena crescer. 🙂

Primeira Descoberta via IP Fabric

Para que possamos fazer nossa varredura pela ferramenta é necessário que alguns ítens iniciais sejam populados, desta forma e como já apresentado nos posts anteriores isso não é feito via SNMP e são feitos através de comandos executados em cada device.

Com isso o primeiro ponto para fazermos a tratativa e termos nosso usuário cadastrado para acesso os equipamentos. Para isso devemos verificar em Settings -> Authentication

Nesta situação podemos adicionar nossa senha e se desejar colocar na aba ( Subnets ) como sendo 0.0.0.0/0, portanto ele vai varrer todo as redes, mas isso pode deixar um pouco mais lento, ou você pode definir que esse usuario esta relacioando a subrede especifica.

Para senha de enable em algumas situações é necessário dependendo de qual vendor você está trabalhando para que de fato você possa pegar algumas informações necessárias.

Após esse procedimento podemo ir na aba de Discovery Seed e se desejar também pode inserir uma subrede ou deixar todas. Como estava consolidando apenas defini a rede do Client A

Snapshot

Após esse procedimento podemos executar nosso snapshot da rede, esperar que os dados sejam populados.

Apoś executar podemos avaliar a varredur, bem como analisar o quanto de banda deixamos habilitada para utilizarmos nessa conectividade. Logo abaixo vemos o gráfico:

Neste momento temos mais dados e logo abaixo já visualizamos os equipamentos sendo descobertos na rede, bem como a demonstração de quantos já foram populados.

Como já informado aqui posso afirmar que não temos nada de SNMP configurado.

Consultar Informações

Para um ínicio básico já podemos consultar as informações capturadas. Logo abaixo você pode verificar através de Diagrams -> Site Diagrams nossa topologia que corresponde ao DC que foi o que eu havia solicitado para ele descobrir através de nossa rede ( Seeds ).

Com isso já temos dados interessantes populados, como STP, Layer 3, Layer 2.

Após isso ainda podemos consolidar quais foram os comandos executados na CLI do equipamento, obviamente através desses comandos ele estruturou as informações para demonstrar isso através do Dashboard. Para os amantes de CLI 🙂 ( assim como eu ) é sempre válido verificar o que de fato foi feito. Segue abaixo o arquivo que você pode fazer download.

Conclusão

De fato como primeira experiência tenho que declarar que as configurações na ferramenta são simples, e os dados capturados trazem de forma clara tópicos que desejamos obter ao longo de nosso dia a dia. Como estou com ambiente virtualizado e uma topologia pequena, eu não consigo afirmar sobre o tempo de processamento para capturar em redes maiores, gigantes, porém isso conseguimos obter através de dados do fabricante.

Em nosso próximo post, iremos agora de fato popular toda a nossa topologia e observar mais afundo alguns detalhes ( MPLS, IGP, Traffic Path, etc )

Fiquem ligados e deixem seus comentários abaixo do que você esta achando de nossa serie ” Netflix “. 🙂

Abs,
Rodrigo

BLOG – Atualização do IP Fabric – Parte 3

Mon, 17 Feb 2020 00:00:00 +0000

Olá Pessoal,

Estamos aqui para mais um post e prometo que esse vocês vão ficar bem animados, pois será de grande utilidade, devido hoje qualquer ferramenta que temos em produção sempre precisamos ficar atentos com as atualizações e de que forma podemos executar isso em nosso dia a dia.

Procedimento

Em nosso procedimento inicial eu instalei a versão 3.3.3 e devido alguns testes que estava executando fui consultar empresa e de fato isso já estava sendo suportado pela nova versão que é denominada 3.4.

A partir desse momento fui validar de que forma executar, e após alguns questionamento aos engenheiros e consolidações podemos fazer de duas formas:

Desde de que tenhamos um pacote adicional para ser instalado, baseando-se em uma nova versão, o updgrade é muito simples, e de pouco impacto ao nosso ambiente de produção, pois temos apenas a necessidade de fazer o download de um único arquivo e proceder com upgrade. Vou detalhar posteriormente esse upgrade\
Caso você tenha uma versão muito antiga e não tenha o pacote adicional para instalação será necessário fazer uma nova instalação, entretanto todas a sua base de dados e informações sobre sua ” base line ” pode ser exportada, para que seja feito upload em sua nova versão.

Upgrade

Para executar o upgrade eu fiz o download do arquivo ( ipfabric-update-3_4_1.tar.gz.sig ) que será inserido para o processo de upgrade.

Para seguir com o procedimento você precisa acessar área de administrador que é feito pelo ” user / password ” definido em nossa instalação inicial.

Após logar com sua senha, nossa próxima menção é acessar a aba ” System Update “.

Normalmente sua máquina de gerência talvez não tenha acesso a Internet, devido a póliticas que você esteja seguindo dentro de sua sua empresa, ou algo de regras de FW, bem como eventos que estão ocorrendo no momento que a ferramenta está tendo alcançar a Internet. Não se preocupe, pois é nesse momento que iremos fazer o upload diretamente.

Após arrastar o arquivo que fizemos download, ele notifica para que seja feito um backup por segurança. Isso é valido também relacionado ao que foi dito no ínicio do post, pois está relacionado sobre sua base line ( estado operacional da sua infra ).

Após carregar o arquivo o processo de atualização acontece em ” background “.

Finalizado o processo, é observado uma janela de que o sistema será reiniciado.

Obs.: Neste ponto talvez, na minha opinião eu acharia interessante ter alguma menção se de fato gostaria de reiniciar agora o servidor ou postergar esse ” reboot “.

Em determinados ambientes de produção, isso pode ser negociado através de uma janela de manutenção, entretanto lembrando-se que essa ferramenta não estaria relacionada com criação de eventos ( ticket ) para a rede sobre seus devices inoperantes, desta forma, talvez essa janela para o reboot, não seja impactante em seu ambiente.

Após reinicialização do servidor, já podemos concretizar que de fato o servidor foi atualizado para a versão que havíamos descarregado ( 3.4.1 ). Segue abaixo através da CLI.

Agora fazendo a consolidação através do portal via WEB ( WEB GUI ).

Conclusão

Podemos notar que de fato atualização pode ser feita facilmente pela browser, o que torna isso muito mais prático e ao mesmo tempo oferecendo uma facilidade para algo que não necessite de um especialista.

Para quem é nativo CLI ( router, switches, etc ) vai entender do que estou falando, pois muitos de vocês já vivenciaram esse mundo e não como nosso grande piada ( Engenheiro Nutella..rsrs )

Obs.: Vale lembrar que é possível fazer atualização via CLI, porém quando existe essa facilidade acabamos nem explorando esses ítens.

Espero que vocês tenham gostado, bem como espero algum comentário abaixo, assim possamos compartilhar ideias.

Abs,
Rodrigo

BLOG – Instalação do IP Fabric – Parte 2

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

Olá Pessoal,

Como vocês podem observar iniciamos uma nova serie de posts, que irá tratar sobre uma nova ferramenta que estou explorando e como não podia ficar de fora vou compartilhar com vocês essas experiências, e de fato é o que eu acho interessante nessa trajetoria.

Como já havia explicado alguns ítens em nosso post anterior, hoje seremos mais direto apenas para demonstrar a instalação inicial, porém como já detalhado não existe muito segredo.

Passos para Instalação

Após fazer o download do arquivo ( .ova ) você pode seguir com a instalação. Lembrando que em nosso ambiente de teste eu estarei utilizando o VMware Workstation.

Inicialmente depois de você selecionar o ” import “ já terá uma opção para escolha relacionado a quantidade devices que a ferramenta irá suportar, ou seja, isso vai estar relacionado com nossa tabela exposta em nosso post anterior, que por sua vez, irá amarrar a quantidade de memoria, espaço em disco para referenciar sua VM.

Em meu homelab selecionei o máximo ( 500 devices ).

Após esse procedimento, seguimos com as consolidações padrões para instalação de nossa VM.

Após as validações anteriores a VM já possui um usuario padrão ( terminal e WEB GUI ) onde agora você irá cadastrar sua senha. Conforme abaixo:

Vale ressaltar que alguns ítens não foram expostos aqui devido a ser um homelab, portanto para instalações em ambientes de produção vale observar os requerimentos ( DNS, NTP, SSL, etc ) ou até solicitar ajuda ao fabricante.

Por fim, verficamos que recebemos um endereço IP ( no meu caso deixei como DHCP ), mas o ideal novamente é reservar um endereço, logo que, isso será sua ferramenta de gerência e não é nada viável depois ficar trocando esse endereço se você tem FW, Políticas, etc. Com isso agora você já pode acessar o IP Fabric via browser e também através do terminal. Veja abaixo:

A partir desse momento você não conseguirá seguir em frente se não obtiver a licença, portanto existe uma forma de fazer uma solicitação TRIAL, e assim desfrutar um pouco dessa ferramenta.

Abaixo segue a página inicial para que você possa inserir sua licença.

ATENÇÃO!!! Após você inserir sua licença um user default é utilizado. Para que você possa logar deve utilizar user: admin /// pwd: netHero!123

Conclusão

Como puderam observar a instalação é bem simples e não existem mistérios, portanto continue seguindo nossos posts que a brincadeira vai começar a ficar empolgante. 🙂

Se você gostaria deixar algum cometário, duvida ou seguestão fique a vontade e pode escrever abaixo que vou fazendo a tratativa.

Abs,
Rodrigo

BLOG – Ferramenta de Gerência e TSHOOT – IPFabric

Wed, 22 Jan 2020 00:00:00 +0000

Bom Dia Pessoal,

Como eu venho fazendo, ou seja, algo que aprendo ou vivencio através de algum canal, sempre gosto depois de compartilhar as experiências. Pois bem, hoje gostaria de compartilhar uma experiência e ideias sobre uma ferramenta que acabei meio que me deparando com ela por acaso.

Entretanto, tenho que confessar que já havia visto que a empresa IPFabric já estava participando do CiscoLive em 2019 e resolvi segui-los pelo Twitter, sempre observando/lendo o que de fato eles estão desenvolvendo, bem como interessado para entender o produto. Depois de um tempo a empresa começou a me seguir no Twitter e resolvi de fato me aprofundar no propósito deles sobre a facilidade de gerenciamento, automação, troubleshooting com historico de eventos, documentação facilitada, etc.

Enfim, após validações e pesquisas verifquei que existe uma forma de solicitar uma licença trial, e tive até a oportunidade de conversar via call com os engenheiros da ferramenta para entender um pouco melhor. Tendo isso, eu agora só preciso repassar isso para vocês, pois tenho que declarar que o proposito dela é muito interessante, e acredito que isso possa ajudar de alguma forma ou no seu dia a dia ou até se estiver pesquisando sobre alguma ferramenta para implementar vale a pena colocar em sua lista.

Empresa

Eles foram fundados em 2015 e hoje já mantém dois escritorios, no qual a matriz fica alocada em Praga ( Republica Checa ) e um escritório em Nova York. A equipe é pequena, onde é composto de engenheiros e programadores, isso deve-se que a ferramenta é intuitiva e muitos parâmetros são automatizados.

O objetivo deles é justamente automatizar documentação de sua rede, através de politicas e capturas de logs, comandos e com isso estruturar todas as informações.

Instalação

Baseado na demanda de mercado, a instalação da ferramenta é bem tranquila baseado que você já pode fazer o download de um arquivo ( .ova ) e disponibilizar isso dentro de seu ambiente, ou seja, diretamente no bare metal ou via uma infra virtualizada.

A documentação deles eu achei bem interessante e prática, pois até o momento daquilo que necessitei pesquisar sempre acabei encontrando de que forma fazer e como fazer. A documentação pode ser visualizada através desse link

Com isso para facilitar para vocês em minha infra ( homelab ) eu fiz o deploy baseado no VMware Workstation para um total máximo de 500 devices e toda a minha infra ( networking ) será baseado em nosso EVE-NG que inicialmente terá equipamentos Cisco e depois ao longo de meus posts vou trazer detalhes sobre Juniper e se possível quero fazer mais alguns testes com outros vendors.

Para rápida consulta você pode visualizar esse dados abaixo sobre quantidade devices x demanda recursos:


Device	CPU	RAM	HDD (OS+Data)
500	4	16 GB	90 GB (80G + 10G)
1000	4	16 GB	100 GB (80G + 20G)
2000	8	32 GB	200 GB (80G + 120G)
5000	12	64 GB	300 GB (80G + 220G)
10000	16	128 GB	550 GB (80G + 470G)
20000	18	256 GB	1000 GB (80G + 920G)

Requisitos Redes ( Devices )

Um ponto importante para eu frizar aqui, é que no inicio eu fiquei muito intrigado, pois essa ferramenta não irá coletar dados de SNMP ou Syslog. Isso foi o ponto mais interessante, pois hoje a maioria das ferramentas sempre trabalham com este intuito.

Talvez vocês me perguntem. OK, então de que forma isso é feito? Pois bem, isso é feito através de coleta de comandos, e com essa base todo o resto é processado para trazer as informações.

Outros questionamentos podem existir, acredito eu você imaginando as possibilidades e alternativas. Sim existe, como eu também pensei. Porquê?

Ela somente funciona para Cisco?
- Não. Existe uma tabela onde são mencionados quais as plataformas são suportadas. Você pode consultar nessa planilha.
SNMP ou Syslog são padrões?
- Infelizmente não, pois em muitos casos ou melhor dizendo ferramentas você precisa fazer o upload das MIBs para capturar as flags corretas de cada vendor, bem como o syslog que também precisa ser tratado e formatado para o output de cada vendor.
Como os comandos são inseridos se o vendor não é suportado?
- A equipe desenvolvimento sempre está atualizando a plataforma, bem como existem roadmaps para essas demandas que também são analisadas com o mercado e a demanda de cada cliente. Porém, posso dizer que é muito mais fácil inserir comandos ( cli ) dos vendors do que executar inserção de MIBs
Essa ferramenta seria para monitoração, ou seja, criar tickets reativos ?
- Esse não é proposito, pois ela obtêm as informações e podem capturar até os eventos baseado em ” snapshots ” que podem ser programados para você entender o que de fato ocorreu nesse evento. Em resumo, você pode pensar usando as terminologias de mercado como sendo uma ” RCA – Root Cause Analysis ” e ” Network Assurance “

Para facilitar segue abaixo um screenshot da propria documentação relacionado aos protocolos e portas que são utilizadas para termos o correto funcionamento.

Como informado anteriormente vou passar o link dos comandos executados que estão na documentação para equipamentos Cisco, e como demonstrado não existe a necessidade de configurar um usuário privilege 15 para os devices, e sim com privilege 1.

Conclusão

De fato até o momento estou gostando sobre o proposito. Em nosso próximo post, vou explicar o passo à passo da instalação e a visualização inicial do dashboard, bem como a topologia inicial que iremos trabalhar para nossos futuros post.

Qual foi sua primeira impressão sobre esse pequeno detalhamento? Você gostaria de obter mais informações sobre o funcionamento?

Deixe seus comentários que esse é o feedaback que tenho se de fato está sendo útil para vocês.

Abs,
Rodrigo

Cisco Meraki – Qualidade de serviço – parte 2

Thu, 03 Jan 2019 00:00:00 +0000

Olá Pessoal,

Como vocês observaram em nosso post anterior, hoje venho aqui para detalhar um pouco mais sobre as opções que temos para ser executadas na infraestrutura de ” Access-Points “. Vale lembrar que a linha para access-point Meraki esta baseado nos modelos denominados MR.

Como havíamos visto anteriormente, eu tenho algumas aplicações mapeadas para que possamos fazer o controle baseado em nosso SSID, que consequentemente teremos a opção para mapear dentro de nossa VLAN. Para isso devemos acessar através de Wireless -> Firewall & Traffic Shaping.

Como podem observar a partir do momento que selecionamos nosso SSID podemos fazer os controles especificos, bem como isso está correspondendo com nosso QoS.

Talvez vocês possam pensar ou perguntar. Mas ele esta fazendo classificação ou de fato está fazendo limitação ” shaping “? De fato, estou fazendo as duas coisas ao mesmo tempo, portanto não espere que você tenha essa separação no dashboard, pois ambos os ítens estão atrelados. Mas porquê?

Nesse caso eu voltaria a pergunta para vocês. Qual objetivo da classificação de pacotes e obviamente porque trabalhamos com QoS?

A ideia neste contexto é justamente você trazer sua aplicação “ Wireless – End points ” para que ela seja limitada ( se desejar ) e também para que possamos classificar esses dados e trafegar ela por toda a nossa rede com sua marcação correta, portanto observamos acima que acabei não criando limites por cliente, porém já temos as aplicações mapeadas. Temos mais um beneficio no portal é que essas aplicações ( mais tradicionais ) já estão mapeadas, portanto somente selecionar aquela que você deseja dentro de cada categoria. 🙂

Em que momento poderíamos pensar nessa limitação através de um SSID? Pense em um caso para trabalharmos em uma rede ” Guest “. Veja abaixo como poderiamos criar esse ” shaping + classification “.

Um ponto sobre as definições de aplicações, na qual acredito que teria muita coisa a melhorar no ” Dashboard “, pois algumas também que são tradicionais não podemos selecionar, portanto temos que trabalhar da mesma forma tradicional em qual temos que ficar definindo na mão ( URL, Portas, Protocol, etc )

Espero que vocês tenham gostado dessa nova facilidade e no próximo post iremos detalhar essas demandas que podemos executar em nossos ” UTM ” conhecidos através dos modelos MX.

Qualquer duvida ou algo adicional deixe seu comentário abaixo. 🙂

Abs,
Rodrigo