Meraki 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

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

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

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

Meraki – Nova Licença – Meraki Insight + Novas Funcionalidades

Tue, 07 Jul 2020 00:00:00 +0000

Olá Pessoal,

Como todos já conhecem sempre venho divulgando novos conteúdos de Meraki em nosso BLOG, e recentemente a Cisco Meraki liberou um novo licenciamento atrelando ao nome “Insight”.

Esse licenciamento está relacionado algumas facilidades que a demanda de Mercado hoje, de fato está exigindo em algumas categorias que vou explicar para vocês.

Desta forma, como em nosso modelo tradicional vocês podem esperar, pois iremos novamente dividir em diversos posts para detalhar um pouco para vocês sobre essas facilidades, bem como explicar como funciona e como configurar, obviamente seguindo a linha de raciocionio Meraki, de ser o mais simples possível e prático para o usuario final.

Detalhamento

Antes que vocês possam perguntar, isso é um licenciamento totalmente segregado das licenças anteriores de Meraki ( Enterprise, Advanced Security ) onde cada uma delas vai atender uma necessidade especifica de sua solução, sempre lembrando que a licença posterior vai cobrir as “ features “ da licença anterior.

Portanto, se é necessario obter esses recursos adicionais em nosso Dahboard, teremos que agregar uma nova licença para nossa organização. Se observarem essa licença está sendo denominada com o nome “ Secure SD-WAN Plus “ que por sua vez, atrela a denominação do nome “ Meraki Insight “. Caso você tem alguma dúvida sobre as licenças recomendo olhar esse post onde existe uma tabela que fica mais nitido para todos.

PS.: Vale ressaltar que essa nova licença terá funcionalidade somente nos equipamentos MX e não atende em equipamento Z-Series, bem como o firmware minimo utilizado nos MXs precisa ser 14.20 ( recomendado 14.21 ou acima ).

Um outro ítem que pode ser mencionado que essa nova licença ou “ features “ adicionais pode ser inseridas nos dois modelo, hoje denominados “ Co-Termination “ e “ PDL – Per Device License “

O que seria o MI ( Meraki Insight )

Nesta filosofia colocando essas funcionalidades, o que de fato irá nos oferecer será uma grande visiblidade dentro de nosso ambiente, segregando alguns elementos ( LAN, WAN, APP ) para que de fato possamos identificar os problemas e melhorar nosso troubleshooting.

Isso de alguma forma acaba-se atrelando a demanda de Mercado , que por sua vez está trazendo cada vez mais essas aplicações nos ambientes compartilhados de Cloud, nomeado como SaaS. Mas, isso não se dá apenas ao fato de ser aplicações em nuvem, pois você também pode customizar a sua propria aplicação para que ela seja validada, sendo assim podemos definir que irá ser “ on-premises “ ou em “ Cloud Hibrída “, baseado em IP ou porta.

Nos poderiamos eleger esses recursos em três pilares:

Saúde da sua aplicação na WEB
Saúde do seu link de acesso ( Internet / Dedicado [MPLS] )
Verificação dos serviços VoIP

Pelos próprios nomes acima, você consegue ter uma idéia sobre o que de fato iremos consolidar em cada elemento, trazendo assim essa visibilidade fim-a-fim.

Premissas

Conforme detalhado acima teremos que utilizar esses recursos através do MX, que por sua vez o principio é que o trafego passe pelo MX ( outbound e inbound ), ou que seu roteamento Interno ( Inter-VLAN ) seja executado por ele através de seus clientes ou das aplicações hospedadas.

Talvez vocês me perguntem. Eu faço o Inter-VLAN no switch Layer 3 que já é Meraki, vou conseguir verificar esses paramêtros? Não, portanto o trafego precisa ser de fato analisando na entrada ou saída pelo MX.

Para isso veja um detalhe abaixo sobre essa menção, bem como sobre a consolidação desse trafego.

Fonte: https://documentation.meraki.com/MI/Meraki_Insight_Introduction

Como podem observar o MX irá trabalhar na mesma característica, executando o encaminhamento no modelo tradicional, porém iremos ter o adicional de uma ” probe “, que está relacionada ao ” Smart Threshold ” validando constantemente aplicação desejada. Em background ele continua reportando todos esses dados coletados para nosso Dashboard, e assim conseguiremos observar o ” status ” das aplicações monitoradas.

Voltando ao nosso ítem de licenciamento, preste muita atenção nesse provisionamento co-relacionando ao seu equipamento, pois isso pode influenciar. Veja abaixo:

Fonte: https://documentation.meraki.com/MI/Meraki_Insight_Introduction

Conclusão

Enfim, vocês podem observar inicialmente que a idéia por tras de todo esse arsenal de informação é oferecer uma maior capacidade de analise de seu ambiente, bem como obter visibilidade, pois hoje em dia como a maioria das aplicações são disponibilizadas como serviços, acabamos ficando de olhos vendados em terminados problemas não sabendo se temos um problema interno ( LAN ), operadora ( WAN ), ou aplicação ( SaaS ).

Em nosso próximo post, irei demonstrar como habilitar o serviço e executar algumas análises inicias nesses dados.

O que vocês acharam? Faz sentido termos esses paramêtros para analise em nosso dia a dia? Deixe seu comentário abaixo. 🙂

Abs,
Rodrigo

BLOG – Meraki IPSEC + Oracle OCI IPSEC – Parte 2

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

Olá Pessoal,

Conforme detalhado em nosso post anterior, hoje iremos fazer algumas tratativas relacionado a criação de uma conectividade entre meu ambiente de homelab com a Oracle Cloud ( OCI ).

Talvez vocês se perguntem o que seria isso? Eu já fiz um post onde eu trazia esse mesmo conceito para uma utilização de infra-estrutura dentro da Azure, desta forma vamos fazer nossa tratativa hoje para executar o procedimento e avaliar as facilidades para Oracle.

Topologia

Temos essa topologia simplificada apenas para que vocês tenham em mente o que de fato iremos construir dentro das estruturas, e a forma de que como isso esta se conectando.

Conceito

Hoje em dia muitas estruturas estão sendo movidas para dentro das clouds, podendo denominar-se como públicas e privadas, ou seja, terá momentos que você irá expor seu serviço para Internet, como também você irá ter apenas serviços denominados para funcionarem internamente em sua empresa, desta forma isso não irá precisar ser visto pelo mundo externo.

Pois bem, em nosso teste iremos tratar como sendo uma VCN ( Virtual Cloud Network ) privada, ou seja, todo esse endereçamento irá responder internamente dentro de meu ambiente. Vale lembrar que por default no ambiente Cloud teremos nossa rede interna sendo definida dentro de uma classe A ( 10.0.0.0/16 ), com isso foi definido neste ambiente cloud que nossas máquinas pertencem a rede ( 10.0.1.0/24 ).

Para que isso ocorra temos a necessidade de efetuar uma conexão ( Site-to-Site ) através de nosso conhecido e famoso IPSEC, entre meu ambiente Meraki e a Cloud Oracle ( OCI ). Portanto, eu irei ter acesso diretamente a qualquer ” Server ” ou ” Client “, sendo acessado diretamente via minha rede Interna Meraki.

Passos para Configuração

Vale lembrar que nesse momento não irei detalhar como executar a criação de instâncias ( VMs ) dentro do ambiente Oracle, e também a criação padrão da VCN, pois isso será explicado em outro post, portanto devo notificar que temos 1 host definido internamente no ambiente Cloud com o IP: 10.0.1.2/24.

A partir desse momento devemos seguir alguns passos para efetuar configuração de conectividade entre os ambientes. Segue abaixo o procedimento:

Criar um CPE ( Customer Premises Equipment )\
Criar um Dynamic Routing Gateways\
Criar o tunnel IPSEC

Configuração passo 1

Por definição a cloud exige que você configure um CPE para termos associações atreladas a esta conectividade, com isso eu criei utilizando uma opção como sendo equipamento Cisco ( temos mais vendor associados ), e posteriormente qual seria o IOS ( ASA ou IOS ), que por sua vez selecione 15.1. Vale lembrar que de fato estou utilizando Meraki ( MX64 ), portanto não faz relação com o IOS selecionado, porém minha opinião que isso seria apenas para atrelar algum vendor e de fato posteriormente ele apresenta ” janelas ” que leva a você ao fabricante, para observar e definir as configurações necessárias para esse vendor. Segue abaixo a configuração:

Após concluir os passos podemos observar que nosso CPE foi criado.

Mais detalhes consulte a documentação Oracle – CPE Configuration.

Escolhemos efetuar as configurações com roteamento estático, pois dentro do ambiente Meraki não temos a opção de subir uma sessão BGP via o tunnel IPSEC ( site-to-site )

Configuração passo 2

Na sequência devemos configurar nosso ” Gateway “, que irá fazer associação ao CPE criado, com isso posteriormente iremos definir ambos os componentes para configuração de nosso próximo passo. Segue abaixo:

Após iniciar ficaremos desta forma as configurações. Neste momento não estou utilizando ” tags “, mas isso para crescimento de sua estrutura pode facilitar para selecionar os serviços corretos.

Configuração Passo 3

Enfim, agora vamos definir nosso tunnel IPSEC com os outros dois componentes criados anteriormente. Para isso devemos ir em Networking -> IPSEC Connections.

No ítem 4 da figura acima é a rota estática que iremos definir para que essa infra-estrutura Cloud possa acessar minha rede local do homelab ( portanto redes atrás do MX ), se tiver mais sub-redes você pode adicionar.

Após isso clique em ” Show Advanced Options ” para selecionar alguns ítens essenciais para seu IPSEC. Um recurso interessante que pode facilitar é que temos como definir via ” FQDN ” seu CPE remoto.

Após isso precisamos definir ” Tunnel ” agregando uma “ shared key ” e a versão do IKE ( já comentado acima ). Vale lembrar que não teremos uma interface tunnel para nosso Meraki, pois iremos criar o tunelamento apenas via o IPSEC.

Após finalizar, pode observar que vai levar uns 5 minutos para o ambiente provisionar essas configurações e logo após você já pode verificar que o status fica ” Available “.

Caso esteja tudo correto em ambos os lados ( Oracle + Meraki ) você poderá observar seu IPSEC está ” UP “.

PS.: Por padrão o dashboard Oracle cria automaticamente dois tunneis para efetuar configuração, tendo dois IP Públicos distintos, porém em nosso lab irei definir apenas 1 tunnel. Oracle usa roteamento assimétrico entre os diferentes tuneis, ou seja, sua VCN pode usar os canais operacionais para devolver para sua estrutura on-premises, ou seja, você precisa controlar esse trafego. Se estiver utilizando BGP você manipula sua metricas.

TIPS: Após a finalização dessa configuração , certifique-se que a ” Security List ” de sua VCN está liberando acesso ao protocolo ICMP “ Ingress ” em sua estrutura.

Configuração MERAKI

Como já exposto em nosso ambiente Meraki, irei definir o MX como sendo um HUB, e após isso devo definir a metodologia ( Phase 1 e Phase 2 ). Para isso, recomendo observar a documentação da Oracle sobre o hash e encriptação para o IPSEC.

Tendo isso em mãos fiz a configuração de uma police “ Custom “, atrelando a ” share Key ” já definida no ambiente de Cloud.

Feito dessa forma iremos ter as informações associadas em nosso ” Dashboard ” como (non-Meraki VPN Peers).

Bem como devemos confirmar qual rede local do meu homelab irá trafegar por essa VPN.

Como demonstrado no dashboard Oracle, aqui também podemos consolidar o status dessa conectividade. Se tudo estiver correto teremos o status “ verde ” 🙂

Consolidação

Nada melhor do que consolidar através de nossas ferramentas essenciais que é o PING e TRACEROUTE ( rsrs ).

Via maquina da homelab ( 192.168.0.0/24 )

Via maquina Oracle Cloud to homelab ( 10.0.1.0/24 )

Conclusão

De fato eu achei bem intuitivo as configurações relacionados ao IPSEC, e consegui estruturar rapidamente para que esse tunel entre os vendor estivessem operacionais. As documentações que precisei pesquisar estavam coerentes e sendo direta ao ponto, sem precisar ficar navegando em diversas abas para obter a informação.

De fato a unica fonte encontrada foi do fabricante, ou seja, não temos ainda muita documentação ou testes executados por esse mundo afora ( rs ). O fato é que cada vez mais está aumentando as informações desse fabricante devido ao seu crescimento nesse segmento.

Em nosso proximo post vou demonstrar como habilitar um serviço http e balancear entre esses servidores. Fique ligado!

Att,
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 – 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 – Meraki e Umbrella – Como investigar os eventos – parte 9

Mon, 09 Dec 2019 00:00:00 +0000

Olá Pessoal,

Para não esquecermos existe uma série muito interessante para você entender sobre essa duas plataformas integradas, portanto recomendo também observar os outros posts e para quem esta seguindo nossa ” dedicatória “ desta solução pode acompanhar que teremos mais um ítem interessante para discutir hoje.

Basicamente hoje a idéia seria explorar as facilidades que temos integrado no Dashboard Umbrella para executar algumas investigações relacionado aos domínios que você está investigando, bem como entender um pouco melhor sobre o domínio em questão.

Uma curiosidade que gostaria de saber de vocês, portanto deixem suas dicas nos comentários, pois quero também aprender. Como vocês investigam os dominios? Quais sites vocês pesquisam sobre os dominios, IP correspondentes, categorias, provedor de hospedagem, DNS autoritativos, etc?

Análise

Para que possamos obter as informações precisamos avaliar dentro do menu ” Investigate “ e pesquisar diretamente pela ” URL “ ou trabalhar como validações usando ” RegEx “.

Para simples validação, vamos obter uma informação relacionado uma situação que acabou ocorrendo, devido algum erro de digitação ou redirecionamentos para nomes as vezes muito parecidos. Nesse nosso exemplo detectei que o Umbrella classificou esse site ” bancointer.co ” como ” Malware “, portanto vamos observar como isso foi definido.

Através desses gráficos temos como detectar a quantidade de solicitações que foram feitas para esse dominio e detectado pelo Umbrella ( Globalmente ) e começamos a ter já algumas suspeitas, pois a quantidade é muito baixa e se correr na linha tempo vamos avaliar que permanece em muitos dos casos abaixo desses valores, bem como você consegue analisar que houve um ” DNS Change ” recentemente, entretanto isso em muitos casos pode acontecer mas é interessante consultar as mudanças.

Para um segundo estágio podemos avaliar quais os endereços IPs estão respondendo para esse serviço e podemos suspeitar que mapeado para esse endereço temos algo co-relacionado a ” Malware “.

Com isso é interessante já consolidar sobre um desses endereços e avaliar quem é o ” owner “ e sua respectiva empresa detentora desse endereço.

Através desse status, para meu exemplo, já verificamos a quantidade de domínios que estão hospedados nesse IP e respondem como sendo um ” Malware “.

Logo após, você ja consegue avaliar os ” resolvers “ sobre esse domínio e avaliar o que temos para consolidar.

Se deseja obter maiores informações sobre o ASN “ Autonomous System Number “, também já é possivel observar diretamente pela ferramenta, bem como ter uma mapeamento interessante sobre qual dominio está respondendo para seu respectivo range de IP.

Volte ao ínicio

E para finalizar com um dominio já categorizado como sendo ” Malware “ evidenciado pela ferramenta e desde de quando isso foi categorizado ( simbolizado pela linha vermelha ).

Conforme também evidenciado podemos fazer algumas consultas utilizando ” pattern search ” que nada mais é relacionado à uma pesquisa mais qualitativa/quantitativa sobre as variações que podemos obter nos endereços de websites. Caso queira entender um pouco melhor sobre a pesquisa utilizando essa técnica, recomendo observar o site da documentação Umbrella, bem como consolidar online se sua pesquisa está relacionando ao fato que você esta buscando.

Conclusão

Eu achei interessante essa parte de investigação, pois de alguma forma ela segue um fluxo para que possamos avaliar alguns domínios, e se de fato são reais ou obscuros ( rs ). Assim, não precisamos percorrer por diversas ferramentas/websites sobre essa investigação.

Para vocês isso faz sentido? Conforme deixei a pergunta no ínicio, vocês seguem esses caminhos para algumas consolidações?

Deixe seu comentário!!!

Abs,
Rodrigo

Cisco Meraki – Inicialização Ansible para primeiro playbook

Mon, 02 Dec 2019 00:00:00 +0000

Olá Pessoal,

Como todos sabem que muitas das vezes eu não consigo atualizar os conteúdos conforme eu desejaria, mas na medida do possível vou sempre atualizando nosso seguidores e comunidade sobre os tópicos que vou aprendendo e desenvolvendo para compartilhar com todos.

Enfim, depois de avançar bastante com tópicos de Meraki + Umbrella, hoje vamos continuar sobre nossos desenvolvimentos baseado em Ansible para controlar seu ambiente, bem como gerenciar as configurações de uma forma mais ágil.

Nos estavamos mencionando nos posts anteriores sobre as capturas que podemos fazer via as API através do Postman. Porém, como vamos iniciar trabalhando dentro do Ansible para chamar algumas solicitações para o Meraki, então nesse momento vou demonstrar algumas ações sendo feitas através de alguns modulos já existentes no Ansible e futuramente coloco algum caso utilizando alguma API dedicada diretamente via Ansible.

API Key para Ansible

Como todos sabemos para acesso ao Meraki precisamos utilizar nossa chave e por consequencia é necessario adicionar esses parametros para o Ansible, pois através dessa ” key ” é que teremos permissões para fazer solicitações ( GET, POST, DELETE, UPDATE ) ao ” Dashboard “.

Não devemos esquecer que o ” Control Node ” que está executando o Ansible deve ter acesso a Internet, já que o produto Meraki está hospedado em Cloud pública. Baseado nessa API Key você também precisa ficar atento que hospedar arquivo host em algum respositório ( Git ), pode expor sua chave de acesso dando permissão ” full ” a toda administração Meraki.

Usando Ansible-Vault

Como informado acima temos que usar algumas técnicas para podermos criptografar nosso arquivo que irá ter nossa ” API Key “ e consequentemente mais algumas informações, que podemos denominar como variáveis para utilização em nossa playbook.

Dentro desta estrutura temos um ítem simples e prático para executar essas ações que esta denominado como sendo função ” ansible-vault “. Como esse não é objetivo principal do post vou executar o mais simples, que é criptografar todo o meu conteúdo no arquivo ( group_vars/auth_key_mer.yml ). Caso queira visualizar mais opções visite a documentação do Ansible-Vault.

Para nosso caso estou criando um novo arquivo para preencher com as varíaveis e logo após estou populando as minhas variavéis que será usada posteriormente. Segue abaixo o exemplo:

Após criação dois ítens estou criando a encriptação do arquivo através de uma senha que estou determinado no momento que executo essa ação. Veja abaixo:

Para demonstrar estou abrindo o arquivo após a encriptação para consolidarmos que de fato esse arquivo foi codificado.

Logo após vocês poderiam perguntar. Como vou editar agora esse arquivo?

Se você observar acima eu posso editar ele normalmente utilizando minha senha, e posteriormente ele irá abrir como um arquivo texto normal, podendo ser editado e salvo da mesma forma que estavamos trabalhando anteriormente.

Vale ressaltar que se por algum motivo você esquecer essa senha, infelizmente você perdeu seu arquivo e terá que construi-ló novamente.

Lógica do Playbook

Como havia informado incialmente vamos utilizar os módulo já populados para Ansible e disponivéis para consumir, pois os proprios fabricantes já desenvolvem para ajudar nesses quesitos. Caso queira saber todos os modulos para o Meraki pode consultar nesse link.

Como feito em outras playbooks que venho utilizando no Ansible, eu criei algumas estruturas para segmentar minhas ” tasks “, e assim fazer as solicitações para ter um pouco mais controle e compreender em qual estado estou de minha playbook e interpretar em alguns momentos os erros que recebo. Segue a estrutura de pastas que criei para esse nosso primeiro exemplo:

Modulo Ansible

Para esse primeiro exemplo escolhi trabalhar com o módulo ” meraki_ssid “ para executar 3 ações que desejo fazer em meu equipamento ” MR “. Desta forma, vou criar um SSID novo, deletar esse SSID e posteriormente vou consultar ” query “ quais SSIDs estão configurados na minha organização.

Novamente, vale ressaltar que neste momento estou criando meu SSID com ítens básico, apenas para ser visualizado no portal, mas caso você queira adicionar mais configurações somente é necessário passar os paramêtros desejados.

Volte ao ínicio

Logo abaixo temos nosso código relacionado ao arquivo ( meraki_basics.yaml ) que será a playbook que irá solicitar todas as demandas baseadas nas opções que eu desejo executar na minha playbook.

---
- name: START CONFIGURATION
  hosts: localhost
  gather_facts: no

  vars_prompt:
  - name: "action_ssid"
    prompt: "Please with action would you like to do?
             ( 1 ) - Add
             ( 2 ) - Delete 
             ( 3 ) - Query"
    private: no

  - name: "ssid_name"
    prompt: "Which SSID name will be (add) or (delete) or query (all)?"
    private: no

  tasks:
  - name: DECRYPT KEYS
    include_vars: "./group_vars/auth_key_mer.yml"
    no_log: true

  - name: GET INFO OF ORG
    include_role:
      name: get_info_org
    no_log: true

  - name: GOING TO ADD SSID
    include_role:
      name: add_ssid
    when: action_ssid == '1'

  - name: GOING TO DELETE SSID
    include_role:
      name: delete_ssid
    when: action_ssid == '2'

  - name: GOING TO QUERY SSID
    include_role:
      name: query_ssid
    when: action_ssid == '3'

Feito isso, eu resolvi criar uma ” task “ dedicada para eu obter todas as informações necessárias do dashboard para que posteriormente eu possa usar qualquer varíavel dentro de outras ” task “. Com isso eu tendo a variável registrada eu consigo obter qualquer variavel pois a estrutura de saída do comando já e formatado em JSON. Segue o codigo relacionado ao arquivo ( get_info_org/tasks/main.yaml ).

---
- name: Query information about Organizations associated to the user
  meraki_organization:
   auth_key: "{{ auth_key_api }}"
   state: query
  delegate_to: localhost
  register: meraki_name
  no_log: true

- name: List all networks associated to the Organization
  meraki_network:
   auth_key: "{{ auth_key_api }}"
   state: query
   org_name: "{{ meraki_name.data[0].name }}"
  delegate_to: localhost
  register: meraki_all_net
  no_log: true

Talvez você me pergunte, porque você está usando ” no_log: true”? Isso deve-se justamente relacionados as informações que podem ser populadas através de uma funcionalidade de ” verbose “ que poderiamos usar para visualizar as informações, mas abaixo você pode detectar que nada é mostrado:

Agora se você observar a saída do comando o qual ele pode trazer, e desta forma podemos filtrar especificamente o valor desejado para sua playbook a partir do momento que estou executando a playbook com ” verbose “ e na minha task foi removido ” no_log: true “

Dando sequencia a nossa playbook iremos consolidar sobre inserção de um novo SSID. Como vocês podem observar estou fazendo a execução desta task, baseado no que o usuario responde a partir do questionamento feito no inicio da playbook, ou seja, essa ação será executada se for preenchida com o ” 1 “. Para que eu possa inserir esse SSID estou colocando o estado como ” present “, assim ele irá escrever e colocar como ” enable “ esse SSID no portal.

---
- name: Adding SSID
  meraki_ssid:
    auth_key: "{{ auth_key_api }}"
    state: present
    org_name: "{{ meraki_name.data[0].name }}"
    net_name: "{{ meraki_all_net.data[0].name }}"
    name: "{{ ssid_name }}"
    enabled: true
  delegate_to: localhost

Logo na sequencia temos o ” delete “ que é a mesma função anterior, porém preciso colocar o estado como ” absent “ e no modo ” enable “ em falso.

---
- name: Delete-Disable SSID
  meraki_ssid:
    auth_key: "{{ auth_key_api }}"
    state: absent
    org_name: "{{ meraki_name.data[0].name }}"
    net_name: "{{ meraki_all_net.data[0].name }}"
    name: "{{ ssid_name }}"
    enabled: false
  delegate_to: localhost

E para finalizar irei colocar uma demanda para fazer ” query “ e fazer ele consultar todos os meus SSIDs configurados, criando assim um loop para ele varrer as variaveis e trazer se de fato o SSID esta habilitado ou desabilitado.

Volte ao ínicio

---
- name: Executing Query
  meraki_ssid:
    auth_key: "{{ auth_key_api }}"
    state: query
    org_name: "{{ meraki_name.data[0].name }}"
    net_name: "{{ meraki_all_net.data[0].name }}"
  with_items: data
  register: status
  delegate_to: localhost

- debug: 
   msg="We found the SSID {{ status.results[0].data[item].name }} in your Meraki Dashboard and enable status is {{ status.results[0].data[item].enabled }} "
  loop: 
    - 0
    - 1
    - 2
    - 3
    - 4

Teste da Playbook

Após vocês entenderem a logica de programação, chegou a hora de verificar se fato está funcionando nossa ideia dentro do portal Meraki.

Neste primeiro teste estou executando como ” ansible-playbook –ask-vault-pass meraki_basics.yaml “, onde a demanda do ” Vault “ é justamente para eu digitar minha senha e poder conseguir obter a variavel desejada que necessito para minhas próximas ações.

Logo abaixo pode observar que estou opção ” 1 “ que irá adicionar um SSID denominado como ” Ansible “.

Agora vou consultar meu portal e consolidar se de fato ele populou meu novo SSID. Confira abaixo:

BINGO!!!

Próximo passo seria deletar esse mesmo SSID e consolidar o que vemos no portal.

Podemos observar que ele já foi removido do portal e por padrão sempre quando não temos o SSID configurado ele irá aparecer como ” Unconfigured SSID x “

Para finalizar vamos consolidar todos os nossos SSIDs configurado e habilitados em nosso Dashboard, utilizando nossa função de ” Query “

Como observamos acima, imprimi todos as saídas para identificar o que temos em operação.

Depois de um longo post, chegamos ao final de mais uma ideia ou iniciativa para começar a manipular seus dados no portal Meraki via Ansible. O que vocês acharam? Vale a pena fazer um video para compartilhar os testes ou ficou bem compreendido?

O que vocês acham que poderiamos mudar nesse código ou o que vocês gostariam que eu demonstrasse para vocês?

Deixe seus comentários, pois esse BLOG é construído para todos.

Abs,
Rodrigo

BLOG – Meraki e Umbrella – APP Discovery automático – parte 8

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

Olá Pessoal,

Gostaria de trazer mais um item adicional e bem interessante que temos na plataforma Umbrella, que esta relacionado a descobertas automáticas das aplicações, à partir do que o usuário esta requisitando ao ambiente.

Hoje em dia são diversas aplicações ” APP “ que cria-se no ambiente público ( Internet ), ou seja, o que escutamos muito em nosso dia a dia é que área de TI pode virar um ” shadow IT “, portanto muito do que esta sendo solicitando ao ambiente, de fato área responsável não tem visibilidade ou nenhum conhecimento do que está trafegando pela sua rede, ou seja, precisamos de algo que nos ajude em nosso dia a dia.

Obviamente que como estamos falando de uma solução de ” Cloud Security “ nossas aplicações aqui demonstradas vão estar relacionadas ao nosso ambiente público, e todos os testes foram baseado em consolidar o status das aplicações encontradas e as formas que são utilizadas para bloquear ou liberar determinados acessos para sua infra-estrutura.

Logo abaixo você pode visualizar a primeira tela que é monstrada e algumas ações/remediações que já podem ser executadas. Como demonstrado já tenho 635 aplicações que posso fazer revisão em meu ambiente e garantir que de fato aquilo que deve ser consultado possa ser aprovado ou talvez reprovado. 😥

Caso você deseje obter gráficos sobre as demandas e correlacionar por níveis de risco, e assim atacar os mais críticos/vulneráveis sempre é o mais recomendado, pois de alguma forma precisam ser consolidados o mais rápido. Se observarem podemos também visualizar a quantidade de solicitações DNS feitas pela organização e obter uma análise dos dias que mais consumos tivemos em nossa infraestrutura.

Logo abaixo podemos obter mais resultados, agora analisando por categoria, e como sempre já podemos observar categoria mais solicitada é ” Advertisements “, ou seja, qualquer site que você entra, já somos inundados de propaganda a todo momento o que nos leva a sempre monitorarmos essas ações, pois em muitos casos alguns scripts ( .js ) são feitos através desses anúncios e acabam tendo alguma ” brecha ” de vulnerabilidade.

Após consultar esses dados podemos de fato partir para análise e observar quais são as aplicações que iremos revisar, bem como quais iremos aprovar ou reprovar dentro da infra-estrutura.

Ao lado você vê a aplicação ” Slack “ e podemos ter varias informações ” insights “ para essa aplicação co-relacionando ela pelas colunas, ou seja, iremos observar quais são as identidades que estão solicitando esse serviço, bem como a quantidade de ” DNS Requests “ e bloqueios que já foram executados, bem como na sequencia temos nosso ” drop down “ para tomar as ações em nossa aplicação.

Talvez vocês me perguntem, porque somente 6% do trafego foi bloqueado para essa aplicação? Verifique nossa resposta abaixo.

Após avaliar essa aplicação podemos acessar-lá e à partir desse momento visualizar algums informações relacionadas a esta aplicação. Como podem visualizar abaixo, temos a descrição de todas as identidades que estão acessando, bem como onde de fato estamos vivenciando os bloqueios.

Para essa situação, meu teste estava relacionado a somente aplicar a regra para os usuarios conectados via tunnel VPN, por isso a temos esses dados relacionados. Caso você queira tomar alguma ação, somente precisamos ir no campo ” Label “ e definir o status para essa aplicação que será mostrada logo abaixo.

Uma outra estatistica é avaliar quais as aplicações que foram aprovadas e garantir que todas elas estão sobre seu domínio de conhecimento e de fato são aplicações conhecidas internamente. Para meu teste fiz algumas consolidações para avaliar as ações que são apresentadas pelas regras e observar se todas elas são incluidas conforme a necessidade.

De fato, elas são aplicadas nas politicas que você deseja e podem ser granular baseado em sua identidades relacionada com as politicas de ” app “.

Para demonstrar ação sobre o bloqueio, vamos selecionar aplicação abaixo e definir que o status será ” Not approved “.

Após essa solicitação vemos em qual das politicas ” APP “ iremos definir que de fato essa aplicação não será acessada.

Após a confirmação para garantir fui consolidar se aplicação está determinada como ” Block “ e como podemos ver de fato ação foi consolidada.

Enfim, chegamos ao final de mais um post. Espero que vocês tenham gostado dessa dica, que de alguma forma pode nos ajudar em nosso dia a dia, já que a visibilidade dentro de nossos ambientes é a principal demanda que devemos observar.

Deixe seus comentários e avise se de alguma forma você já esta utilizando esses recursos.

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

BLOG – Meraki e Umbrella – Criar politicas no portal Umbrella – parte 6

Thu, 31 Oct 2019 00:00:00 +0000

Olá Pessoal,

Nossa serie não para de crescer e temos ainda muito conteúdo para publicar para vocês, portanto não perca nossa trajetoria que muito desse conteúdo está amarrado com os posts anteriores. Caso você tenha caído de paraqueda nesse post, recomendo você olhar desde começo. Acesse nosso conteúdo Meraki+Umbrella.

Como informado, hoje iremos criar nossas políticas e propriamente executar um teste para consolidar nossas regras. Nos já haviamos mencionado nessa serie, mas vale reforçar que as politicas criadas no portal são sequencias ( top-down ), caso uma politica seja atendida baseado nas regras, você não irá executar mais nenhuma regra em sua lista.

Isso também vale para o inverso, que se nenhuma politica relacionado ao seu trafego não coincidir com nenhuma regra, ele irá bater na sua ” Default Policy ” e pode ser bloqueado, ou se você configurou para permitir tudo ( permit any ) você terá acesso, mas não vai garantir a questão de segurança.

Configurar Politica

Para que possamos associar nossas regras sempre pense para qual funcionalidade você estará atrelando essa politica, ou seja, como vimos anteriormente agora chegou a hora de colocar o ” Group Policy “ do Meraki, ou ” SSID “ que você irá dedicar para uma única regra, ou a questão ” VPN Client “ para seguir regras distintas.

Enfim, aqui é dificil colocar uma ” receita de bolo “ das melhores práticas, mas é sempre importante você avaliar as politicas de segurança da sua empresa, ou se não tiver, primeiramente escrever e divulgar para seus usuarios para que isso seja claro e transparente, assim isso não possa gerar maiores impactos área de TI e criando um gargalo devido essa segregação das politicas ou acesso que podem impactar o negocio.

Para iniciarmos a configuração das politicas devemos selecionar qual será nossa identidade para que possamos seguir para os proximos passos. O que seria essa identidades?

Temos várias que podem estar associadas, como ” Tags “, os ” Sites “ como mencionou em nosso post anterior que irá categorizar como seu IP Publico na ponta remota, ” AD Groups “ que pode ser pela autenticação do AD da sua empresa amarrado já diretamente seus usuários, etc. Você podem conferir abaixo:

Na sequencia precisamos definir quais são as categorias que iremos gerenciar para esses acessos. Acredito que a pequena descrição incluida nessa tela pode exemplificar o que de fato estamos controlando. Segue abaixo:

Validação SSL

Após as seleções básica vamos definir algumas configurações avançadas de grande importância, pensando justamente nas caracterisiticas de proxy que iremos utilizar. Veja abaixo:

Como vocês observaram acima, neste momento precisamos avaliar se vamos trabalhar com o certificado ” Root CA “ da Cisco e de que forma iremos fazer a implantação desse certificado. Vale lembrar que isso está atrelado a fazer o ” decrypt “ das conexões SSL, já que de fato hoje a maioria dos websistes/consultas/aplicação ( pequeno ou grande ) já estão trabalhando com essa particularidade e muitos dos ataques podem estar atrelado ao SSL, onde caso você não inspecione podemos ter algum malware atrelado a essa conexão.

As outras facilidades estão relacionadas ao ” Enforce Search “ dos browser, entretanto aqui coloco minha ressalva que a documentação concretiza que isso seria para determinados browsers, e de fato pelos meus testes eles não foram muito efetivos, onde seria para controlar com maior efetividade as pesquisas relacionadas ao temas de ” pornografia “, porém vale avaliar dependendo das politicas de quais browsers podem ser utilizados em sua ” firma ”

Um último parâmetro, mas não o menos importante seria relacionado ao seus logs, como também já haviamos mencionado anteriormente sobre como iremos detectar que nossa politica esta sendo efetiva. Esse parametro é justamente para avaliar o que será guardado e escolher a melhor forma para armazenamento. Aqui vale um lembrete que esses logs acabam ocupando espaço em ” cloud “ e temos uma facilidade que podem ser armazenados esses historicos no S3 da Amazon.

Como vocês podem observar acima, temos duas opções onde se você já tem seu bucket S3 na AWS é facil referenciar, porém se deseja que a Cisco gerencie pode ser utilizado opção abaixo e o máximo de retenção que iremos ter será de 30 dias. Caso queira entender um pouco mais é interessante avaliar a documentaçãoavaliar a documentação, pois muitas empresas desejam ou utilizam outras ferramentas para correlacionar eventos, onde entra o papel do SIEM ( Security Information and event Management ).

Volte ao ínicio

Granularidade da Política

Como vamos observar abaixo, existe varias opções para criar sua granularidade de acesso para seu usuario e obviamente controlar a nível de ” DNS enforcing “ o que pode ser acessado ou bloqueado em sua infra-estrutura. Para sequencia agora vamos definir o nivel de segurança para essa politica.

Logo após entramos para os parâmetros das categorias de sites, ou seja, todo o site na Internet é classificado baseado em seu conteúdo ( Chat, Social, Games, etc ), com isso podemos selecionar em qual nivel iremos trabalhar ou criar um ” Custom “ baseado em sua politica interna. Segue abaixo:

Como em muitas situações ainda podemos ser mais especificos baseando-se na aplicação que devemos observar, segue abaixo varias aplicações mapeadas que podem ainda serem selecionadas para confrontar com sua politica ( Facebook, Mail.ru, etc ).

Um ítem importante você ainda pode criar lista destinos para acessos aos sites. Conforme no meu teste criei uma lista de teste para bloquear qualquer acesso ao dominio ” UOL “.

Volte ao ínicio

No proximo passo se você deseja fazer inspeção de arquivos que estariam relacionados aos downloads e validação para Malware, para qual estarão correlacionado as assinaturas e que todo o grupo do Cisco Talos trabalha em ” background “ para avaliar esses comportamentos.

E agora como você deseja mostrar a tela para seu usuário final informando que ela foi bloqueada? Por padrão existe do Cisco Umbrella, mas se deseja customizar sua própria pagina é possivel, bem como redirecionar para uma nova página que pode estar atrelado ao seu Service Desk, ou algum pagina interna de sua empresa

Como testar a politica

Bom, agora vamos testar confrontando se o site que desejamos esta sendo bloqueado ou liberado relacionando ele com nossa politica.

Primeiramente devemos clicar em ” Test “ e as setas vermelhas seguintes precisam ser preenchidas para que você selecione qual identidade deseja testar e qual seria seu destino. Após isso nas setas verdes você pode avaliar sua resposta.

Desta forma, você olha porque ele foi bloqueado ( relacionado a regra ” Destination List ) e em qual política ela se enquadrou.

Bem como também você vai observar status de liberação, caso isso seja desejado.

Desta forma chegamos em mais um final de post. O que você esta achando de nossas explicações? Está sendo útil? O que você deseja verificar mais nessa solução?

Deixe seus comentários.

E tenho mais informação para divulgar para vocês aqui dessa serie. 😉

Abs,
Rodrigo

BLOG – Meraki e Umbrella – Como visualizar as Redes e Equipamentos no Umbrella – parte 5

Mon, 28 Oct 2019 00:00:00 +0000

Olá Pessoal,

Como estamos tratando dessas duas soluções, mas ao mesmo tempo em uma única solução, hoje vamos apresentar como são evidenciado os dados que requisitamos de sincronização do Meraki para o Umbrella.

Quando inicia-se na plataforma Umbrella, um dos primeiros ítens que irá aparecer é se você gostaria de associar seu endereço Público, aqui vale lembrar que ele mapeia com seu IP publico que você está utilizando para navegar na Internet e solicita para registrar esse endereço, fazendo com que todos os endereços atrás do ” Public IP “ serão protegidos utilizando assim um camada de segurança.

Caso você não esteja na estrutura desejada ou esta associado há uma conexão 4G Publica, WIFI do café, rede cabeada da escola, obviamente isso não faz muito sentido fazer o registro, entretando também não é primordial para seguir para seus próximo passos.

Em meu caso eu registrei para declarar meu IP Público e também para fazer testes baseado no que diz respeito a ter esse IP Dinamico pela operadora, já observando para as implementações Meraki ( MX ) que você tenha em campo e queira associar na sua última política ( Default Policy ) para o Umbrella. Para registro é bem simples como abaixo, porém devido a ser dinamico você precisa prestar atenção que caso aquele site/spoke/escritorio venha a trocar o IP ele consiga atualizar dinâmicamente no portal.

Para isso temos um post sobre o OpenDNS onde a demanda para esse caso será idêntica, portanto valide através da nossa dica.

Umbrella – Network Device

Nos posts anteriores vimos que para associar ” Group Policy “ ou ” SSID “ precisaríamos criar nossa conexão ( API ) entre as duas soluções, isso após a execução iremos visualizar desta forma no portal Umbrella. A coluna ” Device Name “ é editável para que isso reflita-se nos relatórios que podem ser gerados pela ferramenta.

Na coluna ” Primary Policy “ é o que concretiza a união das politicas com as demandas solicitadas via Meraki API. Um ponto importante sobre o ” Status “ é que você pode não ver ele rapidamente mudando para ” Active “ no momento que sua rede começa a trafegar dentro dessa policy, ou seja, podemos ter no máximo 24 horas para ir para ” Active “ e o inverso também é válido, portanto depois que sua rede/usuário parou de solicitar serviço pode demorar 24 horas para ficar ” Offline “.

Talvez você me pergunte como vou ficar sabendo se esta funcionando?

1. Você pode consultar através do relatório instantâneo, depois de requisitado liberado ou bloqueado, demora em torno de 1 minuto para poder visualizar o log.
2. Você pode testar através de sua politica em um formato de ” Policy Tester “

PS.: Esses dois exemplos eu ainda vou detalhar em nossos próximos posts relacionado especificamente a criação das políticas no Umbrella.

Roaming Clients

Essa é uma demanda muito interessante para nossos ambientes corporativos, pois vai tratar de usuarios que de alguma forma não estão sempre conectados ao nosso ambiente ( cabeada, Wireless, Guest, etc ), ou seja, não estão em seu perimetro e assim você não tem controle sobre eles.

Quando esse usuario acessa algum ambiente externo você pode força-lo a sempre executar sua politica, desta forma você garante controle de acesso e segurança para seu usuario e ” end-point “. Pensando desta forma, para facilitar existe algumas metodologias para implementar na máquina do usuário:

- Pode fazer o download diretamente do portal para instalar na máquina, como indicado na figura abaixo
- Pode instalar via GPO, quando o usuario logar em seu dominio
  - Sem usuário visualizar no gerenciador de programas
  - Sem usuário obter a interface visual
  - Sem usuário obter na aba de remover programas

Enfim, temos diversas possibilidades para oferecer essa camada de segurança e podemos conferir acima que após a máquina navegar pela internet conseguimos avaliar que o usuario está online e qual a politica esta sendo utilizando para esse úsuarios/computador.

No meu caso como quero demonstrar para vocês, eu executei via processo NNF ( Next->Next-> Finish ) em uma máquina Windows 10, portanto eu consigo visualizar que o programa esta na barra de tarefas e o ” client ” esta atuando conforme minha políticas.

Logo abaixo você pode conferir que meu ” end-point “ esta associado as politicas, bem como garantir que esta para organização que evidencia sua regras.

Caso vocês queiram saber um pouco mais sobre essas demandas de roaming clients eu recomendo observar a documentação, ou se desejarem, posso fazer um post dedicado com essa demanda e com os testes. Deixe sua menção em nossos comentário que planejo o post somente sobre esse ítem.

Existem outras demandas que podemos explorar que a propria ferramenta oferece, porém não vou detalhar aqui devido a não tempo disponível para conseguir planejar as estruturas. Porém, podemos visualizar demandas relacionadas MDM ( Mobile Device ) gerenciando esses acesso através por exemplo de uma solução Meraki MDM com Umbrella e também estruturas usando Chromebooks.

Chegamos no final de mais um post, UFA!!! Espero que vocês estejam gostando e no proximo vou me aprofundar nas possibilidades de executar a criação das politicas no Cisco Umbrella.

Deixem seus comentários abaixo para entender se esta sendo claro o que estou demonstrando e se vocês querem mais detalhes.

Abs,
Rodrigo

BLOG – Meraki e Umbrella – Iniciando no portal Umbrella – parte 4

Thu, 24 Oct 2019 00:00:00 +0000

Olá Pessoal,

Como estamos fazendo nossas tratativa nesses dois ambientes, espero agora trazer um pouco de familiaridade para esse novo Dashboard, e de alguma forma eu consiga demonstrar um pouco do que aprendi durante esse tutorial que estou criando para vocês.

Enfim, nesse primeiro momento e como estamos fazendo algumas tratativas de segurança, nada melhor iniciar demonstrando como podemos criar regras de acesso para essa plataforma, pois nela teremos todos os dados de acesso a rede ( Internet ) de sua corporação, por isso vale relembrar que o controle dos usuarios para a plataforma precisa ser gerenciado de uma forma correta.

Para isso, vamos iniciar com um ítem hoje em dia muito importante que é autenticação com 2FA ( Two Factor-Authentication ). Nós já haviamos demonstrado isso no portal Meraki, por isso achei importante já iniciarmos com esses critérios.

Criar Autenticação ( 2FA )

Após você acessar sua conta devemos seguir para a menu Admin -> Authentication, e abaixo já podemos visualizar duas formas de gerenciar sua autenticação ( SAML ), onde temos várias opções hoje no mercado para trabalhar desta forma, o qual posso dizer que Okta é um serviço bem interessante, porém nosso objetivo seria via 2FA.

Após seguir os procedimentos para habilitar, eu fiz um teste usando um novo autenticador que a Cisco adquiriu recentemente para trabalhar internamente com suas ferramentas e os serviços para autenticação em nuvem que você pode utilizar para esse proposto. Essa empresa adquirida por eles é a DUO onde você tem um plano free para utilizar esse autenticador, não somente com o Umbrella, mas com outros vendor que oferecem autenticação 2FA ( via software ) e não somente via SMS ( o que não é seguro ).

Após a criação da autenticação a tela abaixo é requisitada para seu acesso, assim como em outras ferramentas que utilizam esse formato.

Política de Usuários

Neste meu exemplo precisamos ter o usuário ” root “ que por sua vez terá o acesso ” full “ para toda a ferramenta. Isso quer dizer que através dele posso definir os outros usuarios que teram acesso a ferramenta.

PS.: Uma dica o time zone dependendo do usuario criado vai influenciar diretamente nas consulta dos relatorios de acesso e segurança.

O nível de usuario padrão que temos especificado no portal é conforme abaixo:

Como indicado na ” seta “, podemos também adicionar perfis customizados para definições que desejamos e queiram ser agregado em mais de uma ” role “ sem ter o privilegio ” full “. Para isso iremos ter essas definições:

Após essas definições você pode agora associar seu usuario para fazer autenticação no portal atrelado o que foi especificado para acesso.

Com isso concluímos a primeira etapa e a descoberta para inicializarmos no portal, já definindo algumas politicas de segurança. 😛

Isso deve-se a ter um controle maior para acesso ao portal e aos usuarios que de alguma forma precisam avaliar o que esta acontecendo na infra-estrutura e também para executar algum troubleshooting.

Espero que vocês tenham gostado e qualquer dica ou sugestão coloquem em nossos comentários. Fiquem ligados que temos muito mais para demonstrar para vocês.

Abs,
Rodrigo

BLOG – Meraki e Umbrella – Criar as políticas e Aplicar – Parte 3

Mon, 21 Oct 2019 00:00:00 +0000

Olá Pessoal,

Como vocês vêem acompanhando nossa serie de integração desses dois produtos, vamos detalhar hoje um pouco mais de que forma vamos aplicar isso na estrutura Meraki e quais os equipamentos que irão aceitar essas configurações.

Para quem não viu nossos posts anteriores, recomendo ler para que você possa executar esses próximos passos e consiga concluir essa integração.

Associar Politicas

Neste momento existem duas facilidades para que você possa associar suas politicas Umbrella com o Meraki através do portal:

- Group Policy: Essa metodologia é importante para que você possa associar uma VLAN que é utilizada via cabo ou talvez se você utiliza o MX como um HUB de VPN, tendo assim seus usuarios associados esta VPN.
- SSID: A partir do momento que mencionamos SSID, obviamente estamos atrelando isso ao nosso MR que por sua vez irá aplicar especificamente para aquele rede que esta configurada para sua estrutura. Neste momento não vou entrar em detalhes sobre a configuração do SSID e associação com VLANs, mas isso pode ser tratado posteriormente em outro post.

Iremos ter uma terceira opção para executar essa associação diretamente através do MX, porém ainda esta em fase de teste ( BETA ) para que os clientes possam avaliar. Entretanto eu vejo uma função muito importante para que possamos remover a dependência de criar diferentes ” Group Policy “.

Criar Group Policy

Para que possamos criar nosso grupo police devemos ir Network-wide > Configure > Group policiesgarantir que opção ‘Custom network firewall & shaping rules‘ esteja selecionada, pois apenas desta forma que iremos ter a funcionalidade habilitada no portal.

Antes de tentar associar a politica Umbrella certifique que você já salvou seu ” Group Policy “, para que isso reflita em ambos os portais.

Verifique abaixo de que forma você irá visualizar essa funcionalidade.

Aplicar a politica no Group Policy

Após a execução dos passos anteriores você deve agora visualizar que a politica existente no portal Umbrella irá aparecer, para que você possa selecionar a enquadra-se em suas diretrizes. Veja abaixo:

PS.: Por padrão a partir desse momento sempre será visualizado a ” Default Policy “ para ser selecionada, pois no portal Umbrella essa seria a politica padrão caso nenhuma politica de accesso se enquadre em seus requisitos e que por consequência essas politicas criadas no Umbrella segue uma sequência. Para quem esta acostumado a visualizar ACL vai entender esse conceito e caso queira entender melhor no Umbrella é recomendado consultar a documentação ” Policy Precedence “

Baseado na criação do ” group policy “ e se você deseja aplicar essa politica para seus usuários que utilizam a aquela VLAN especifica que está definida para sua sua rede cabeada, por exemplo, ou que você deseja aplicar para toda a sua sub-rede é necessario executar isso através Security & SD-WAN > Configure > Addressing & VLANs

Vale lembrar, que no momento que está aplicado para toda a sua sub-rede, esta demanda está sendo executada no MX e também precisamos garantir que os usuários estão associados esse group policy

Aplicar Politica no SSID

Como comentado anteriormente agora vamos associar uma politica basedo em seu SSID, que por muitas vezes se torna essencial e prático para questões de gerenciamento de acesso. Isso vale, pois precisamos definir para alguns casos ou exemplos para o SSID Guest, SSID MDM ou SSID Corporativo e assim por sua vez alguns desses SSID já estarão utilizando uma VLAN que de fato já é utilizada para seu ambiente como um todo, porém será aplicado politicas distintas.

Para isso vamos acessar nosso SSID ( não irei detalhar aqui como criar o SSID ) através do Wireless > Configure > Firewall & traffic shaping

Desta forma você irá selecionar qual a politica definida no portal Umbrella, bem como logo abaixo uma menção sobre o ” Exclude “. Isso deve-se se por alguma razão, onde precisamos excluir solicitações de nomes de dominio que não precisam ser direcionados para o Cisco Umbrella. Um ítem que você pode pensar rapidamente é justamente o link ” setup.meraki.com “ que direciona você para avaliar sua conexão local e outros ítens. Você pode obter mais detalhes em nosso post.

Para a demanda de utilização do SSID, seguimos da mesma forma em relação a regra criada no Umbrella, que por sua vez ele vai seguir as políticas na sequência, já mencionado no ” Policy Precedence “

Remover a Política

Caso você resolva remover a politica ou remover a conexão daquele SSID ou de seu ” Group Policy “, o que necessitamos fazer é somente acessar seu ítem e desabilitar usa conexão, conforme abaixo:

Fluxo da Solicitação DNS

Segue abaixo como essas solicitações são direcionadas através de nossos dois exemplos mencionados acima:

Cliente solicita DNS Query.
Meraki intercepta o DNS Query e adiciona uma identificador para validar qual politica deve ser validar com Cisco Umbrella.
Meraki encripta esse DNS query usando o DNScrpt.
Depois de chegar essa solicitação no Umbrella ele é decriptado e validado com a política correta, basedo no identificador executado no passo 2.
Caso a solicitação seja liberada ele retorna um DNS response encriptado com sua devida resposta ( IP do website ).
Caso a solicitação seja negada ele retorna um DNS response encriptado direcionando você para uma pagina de notificação ( Block Page ).
Cliente é enviado para o website requisitado.

Espero que vocês tenham gostado e se ficou alguma dúvida coloque em nossos comentários que iremos respondendo. 😉

Em nosso próximo post irei detalhar sobre os recursos expostos dentro do Cisco Umbrella, continue ligado que temos muito conteúdo para detalhar para vocês.

Abs,
Rodrigo

BLOG – Habilitar API Key – Meraki e Umbrella – Parte 2

Wed, 16 Oct 2019 00:00:00 +0000

Olá Pessoal,

Como iniciado em nosso post anterior, vamos detalhar hoje como devemos fazer nossa integração entre Meraki ( MX ) e Cisco Umbrella.

Para que possamos habilitar essa funcionalidade segue abaixo alguns requisitos mínimos que precisamos ter em nossa solução Meraki para conseguir trabalhar com esse recurso adicional. Vale ressaltar que essa demanda pode ser executada nos equipamentos MX e MR.

Requisitos Meraki

Como informado acima podemos habilitar a funcionalidade nas linhas MX e MR. Talvez me perguntem, porque aplicar isso em um Access Point ( MR )? A resposta é simples, pois hoje os MRs podem ser disponibilizados diretamente com um link de internet e devido a isso você pode criar suas ” policies “ diretamente nele sem a necessidade de um MX.

- - MX – Precisamos ter no mínimo o firmware 15.10+ e a licença Advanced Security
  - MR – Precisamos ter no mínimo o firmware 26.1+

Para detalhamento desse trafego segue uma topologia para o entendimento do fluxo que nosso tráfego irá executar.

Fonte: https://documentation.meraki.com/MR

Configuração

Como vocês puderam observar no título de fato a integração é muito rápida, pois precisamos habilitar apenas uma API no portal Cisco Umbrella, após isso essa chave é adicionada na portal Meraki e tudo já está resolvido.

Para isso vamos criar nossa API conforme abaixo no portal Cisco Umbrella.

PS.: Em nosso caso como vamos utilizar a infra Meraki devemos ficar atento para selecionarmos ***” Umbrella Network Devices ”***e seguir os passos como indicado na figura.

Após isso iremos copiar e colar essas informações em nosso portal Meraki através do menu Network-wide > Configure > General

Caso você precise deletar sua integração e todas suas configurações entre Meraki e Umbrella, basta apenas selecionar a caixa ” Deleted linked account “ e você verá que todas suas definições no portal Meraki e Umbrella serão deletados.

Talvez você gostaria de fazer um teste em seu ambiente utilizando o Cisco Umbrella, e posso afirmar que isso é factível, devido a ter uma teste gratuito full license durante 14 dias. Se desejar você pode fazer seu cadastro através desse link ” Umbrella free 14 days “.

Licença Umbrella

Como detalhamos os requisitos mínimos para executar no Meraki, gostaria também deixar uma pequena informação sobre o licenciamento Umbrella, que pode variar dependendo dos requisitos que você queira atender no plataforma Umbrella.

Fonte: https://umbrella.cisco.com/products/packages

O que vocês estão achando? Se segura na cadeira que vamos entrar no modo configuração. 😈

Abs,
Rodrigo

BLOG – Cisco Umbrella + Meraki

Mon, 14 Oct 2019 00:00:00 +0000

Olá Pessoal,

Gostaria de iniciar mais uma serie de post que iremos trabalhar para detalhar essa solução que temos hoje entre a integração de Cisco Meraki com Cisco Umbrella.

Acredito que todos aqui já devem conhecer um pouco de Meraki, pois venho trazendo muito conteúdo sobre essa solução, porém vocês poderia perguntar. O que é Cisco Umbrella?

Cisco Umbrella

Esse é um produto da Cisco que esta atrelado a torre de Segurança, porém relacionado a terminologia denominada ” Cloud Security “, que por sua vez será relacionado a demanda de controle/visibilidade para acesso ao ambiente de internet.

Talvez vocês possam fazer associação a este produto com o OPENDNS, e de fato seria essa associação que devemos fazer, pois é o mesmo produto, porém com a formatação Cisco para segmento Enterprise depois de alguns anos que foi consolidado a compra em 2015. Você pode conferir neste link.

Você já pode conferir em nosso BLOG quando trouxemos o OpenDNS para um ambiente mais doméstico, onde temos um serviço free que pode ajudar no seu dia a dia, entretanto nesta serie iremos trazer uma demanda maior para utilização em nosso ambiente corporativo e com uma escabilidade muito rápida e dinâmica.

Nos dia atuais nós temos um ambiente muito vulnéravel denominado Internet, e podemos mencionar que a demanda é totalmente ascendente para esse ambiente, onde cada vez mais é solicitado. Isso deve-se a muitos fatores que estão contribuindo para essa escalabilidade, como:

- - Tecnologia de mais fácil acesso
  - Custo mais acessível
  - Largura de banda muito acessível e escalável
  - Ferramentas corporativas muito mais acessível e escalável
  - Cloud pública com uma forte demanda para ofertas de serviços ” SaaS “
  - Ponto de comutação para trazer tecnologia + redução de custo ” SDWan “

Enfim, temos inúmeros pontos para colocar os ítens relacionado à essa crescente utilização na demanda para ambientes públicos ” Internet “, entretanto em contrapartida também devido a isso acaba sendo um ambiente muito vulnerável, ou seja, para seu prospecto corporativo isso tem também inúmeros riscos para seu negócio.

Portanto, precisamos analisar bem nosso ambiente e controlar o que de fato PODE ou NÃO PODE ser acessado pelos seus usuários e garantir a integridade de seus dados. Talvez vocês me questionem, nossa mas o que ele esta falando é muito antigo e o tópico que ele esta explicando eu já faço a muito tempo.

O que seria? Sim, seria nosso famoso e conhecido ” PROXY “. ( rs )

Mas agora volto a pergunta para vocês. Qual é o diferencial de ter esse proxy em Cloud? Em qual camada vou trabalhar para controlar esse recurso?

Deixem seus comentários abaixo e continuem nos seguindo que os próximos posts vamos agregar mais conteúdo e demonstração das ferramentas.

Documentação

Para você que gosta de ler/pesquisar sobre essas demandas a documentação do Cisco Umbrella é bem simples e didática, portanto recomendo dar uma olhada para entender o que vamos explicar em nossos próximos posts.

Abs,
Rodrigo

PS.: Não esqueça deixar seus comentários. 😛

Cisco Meraki – Configurado Site to Site com Azure

Mon, 23 Sep 2019 00:00:00 +0000

Olá Pessoal,

Como vocês sabem a todo momento estou trazendo ítens adicionais para facilitar e oferecer escalabilidade dentro das estruturas Meraki, e hoje venho aqui trazer mais um teste executado e para alguns clientes finais, bem como para as corporações será de grande utilidade.

Porque digo isso? É porque hoje temos muitas estruturas que estão sendo disponibilizadas nos provedores de cloud ( Azure, AWS, GCP, IBM, Alibaba, etc ). Desta forma, precisamos oferecer escalabilidade para nossos pontos remotos, fazendo que via uma Infra Pública ou Privada você continue utilizando seus recursos em seus parceiros.

Com isso vem também a pergunta, Meraki pode-se conectar diretamente com esses parceiros? Você não consegue fechar uma VPN/Tunnel somente com equipamentos Meraki? Como é feito esse tipo de configuração?

Pois bem, recomendo você seguir nosso post que iremos detalhar todas essas dúvidas. 😉

Definição da Topologia

Para iniciarmos gostaria detalhar um pouco como esta nosso cenário, para que a partir dele vocês possam pensar se de alguma forma atende as suas necessidades, e as possíveis alterações que possa ser inserido conforme seu ambiente cresça internamente ( on-premises ) ou aplicações em Cloud.

Vale ressaltar que aqui estou simulando como sendo um HUB ( Meraki ) e por consequência ele pode ser considerado um Datacenter ou até mesmo um Spoke ( Meraki ), entretanto existem algumas restrições que estariam relacionados a sua estrutura na Cloud. Segue abaixo minha topologia:

Detalhamento da Tecnologia

Para criar essa demanda, foi utilizada uma conta ( Free Trial ) na Azure para que pudêssemos instalar os componentes necessários para esse ambiente. Após ler a documentação da Azure, identifiquei que temos a possibilidade de criar um tunnel IPSEC diretamente através de um componente denominado como ” VPN Gateway ” e com isso não haveria a necessidade de termos um vMX100 da Meraki instalado através do marketplace .

Entretanto, devido a não termos instalado um vMX, muito dos componentes e funcionalidades Meraki não será utilizada, mas o proposito aqui é justamente iniciar uma VPN ( Point-to-Point ) entre um device Meraki ( MX ) com uma estrutura de terceiros. Aqui podemos também pensar que esse terceiro seria um roteador Cisco ou Firewall Cisco.

Sempre que pensamos em nuvem precisamos observar as especificações/capacidade de cada componente para que você possa fazer o ” deploy ” de maneira correta, com isso existe as especificações conforme abaixo:

Para maiores detalhes sobre essas especificações recomendo observar neste link da Azure. Seguindo nossa linha detalhamento, temos que observar que Meraki utiliza apenas IKEv1, com isso precisamos observar que o ” VPN Gateway Azure ” no modo ” Basic ” não consegue fazer negociação em IKEv2, portanto se esse tutorial ajudar a montar essa estrutura com outro vendor é importante observar esse detalhe.

Com esses dados em mãos precisamos iniciar os trabalhos e subir a infra-estrutura na cloud para que possamos receber essa conexão vindo de nosso Meraki. Para esse parâmetro recomendo ler esse documento que detalha como criar seu ” VPN Gateway “, mas aqui também vou dar algumas dicas e as telas dedicadas para nosso ambiente.

Para meu ambiente eu criei um ” Resource Group ” dedicado para esse teste, conforme podem observar abaixo:

Antes de criar nosso VPN Gateway é necessário criar nossa rede virtual ” VNET “, para que seja nosso ponto de segmentação em nosso ambiente. Se desejar obter maiores detalhes você pode consultar a documentação do ” Virtual Network “, e mais abaixo você pode encontrar ele para adicionar em seu ” resource group “.

Com isso agora vamos criar nosso range relacionado ao nosso ” Address space ” que por consequencia eu coloquei o /16, pois a partir deles vamos criar as segmentações ( VLANs ) dentro dessa VNET. Portanto, foi definido uma sub-rede para eu associar uma máquina virtual, e assim efetuar apenas os testes básicos posteriormente. Segue abaixo a relação das definições:

Caso em um futuro próximo você deseje adicionar mais VLANs dentro de seu segmento, você pode facilmente criar conforme abaixo:

Após isso você irá adicionar seu “ Virtual Network Gateway “, ele que de fato é seu ” appliance virtual ” que irá processar todos seus dados que irão ser encaminhados para sua estrutura virtual, ou muitas das vezes também podemos denominar como ” HUB “.

Quando fizer o deploy do VPN Gateway, alguns parâmetros precisam ser preenchidos para que o processo seja finalizado e de fato ele seja instalado dentro de seu resource group. Em algumas situações o deploy dessa instância pode levar uns bons minutos. ( 15 a 20 minutos ).

Na figura acima podemos observar que estou definindo um nome para meu ” Gateway “. Como explicado anteriormente, olhando para o cenário Meraki ( S2S com vendor distinto ) necessitamos selecionar o ” Policy-Based ” que está atrelado automaticamente SKU ” Basic “, bem como essa função precisa ser selecionada, pois nossa VPN no Meraki não teremos a possibilidade de configurar roteamento dinâmico, e sim ele vai usar uma ” rota estática ” apontando para esse tunnel IPSEC. Temos um recurso para selecionar esse failover de tunnel no Meraki, utilizando ” TAGs “, mas irei detalhar posteriormente essa demanda.

Outro detalhe que estou criando um novo IP Público, pois não tenho reserva de IP Público na Cloud, porém a partir do momento que seu Gateway Azure adquirir um IP Publico da Cloud, ele sempre irá ser fixado para você, desta forma seus spokes podem sempre fechar no mesmo IP.

Neste momento precisamos criar nosso “ Local Network Gateway “, para que possamos associar nosso endereço público ” Meraki ” com a nossa Cloud, bem como mencionar para ele quais são os endereços que iremos buscar do outro lado do Meraki, ou seja, a sua LAN que está atrás de seu MX. Neste caso temos opção de BGP, mas para nosso exemplo não foi configurado pelos parametros já mencionados anteriormente.

A rede adicionada como 192.168.2.0/27 será para demonstrar para vocês sobre o controle que temos em ambos os lados ( Cloud e Meraki MX ), pois nesse segmento atrás do MX é de clientes que podem fechar uma VPN como o MX, que por consequencia ele também irá oferecer todos os serviços que estão hospedados na Cloud.

Finalmente agora iremos configurar nossa conexão ( ShareKey, Gateway, Tipo de Conexão ). Para isso devemos ir em nosso local network gateway executado acima para configurar. Verifique abaixo:

Após, você configurar seu Meraki poderá observar o status da conexão no portal através dessa nova conexão.

Devido a todo esse processo, resolvi criar uma maquina virtual Ubuntu para que eu pudesse adquirir um IP Privado na minha ” VNET ” e assim eu pudesse fazer as validações relacionadas a caminho ( traceroute ) e a disponibilidade ( ping ). A única disponivel de fato nos ” marketplace ” é sempre Server, mas não tenho nenhum serviço que é de fato necessário para nosso teste, será para adquirir apenas um IP Privado na interface e possamos fazer de minha máquina ” on-premise ” chegando na cloud. Segue a imagem que usei abaixo:

Volte ao ínicio

Detalhamento sobre VPN ( S2S ) no Meraki

Para nossa demanda dentro do portal Meraki temos poucas configurações para executar, pois ele de fato é simples e objetivo. Entretanto, devemos ressaltar que para concretizar a configuração de seu MX, precisamos definir ele como ” HUB ” ou ” Spoke ” e assim você terá opção de fazer o conexão ponto a ponto ( VPN ). Para isso devemos validar acessando Security & SD-WAN -> Site-to-Site VPN conforme abaixo:

Após esse processo, vamos definir as configurações do meu peer que foi criado na Cloud, bem como vocês pode perceber que aqui também vamos definir quais são endereços que estão atrás do meu ” Virtual Gateway Network ” e nossa key definida anteriormente na cloud.

Talvez vocês me perguntem, como ele adicionou as policies relacionado ao IPSEC. Aqui que temos as facilidades, pois já está tudo definido as politicas mais usuais baseado no seu fornecedor de Cloud que você esta fechando sua VPN. Logo abaixo você já pode observar as politicas tradicionais ( Phase 1 e Phase 2 ) para Azure.

Com isso finalizamos nossas configurações relacionadas ao ambiente Meraki, e assim devemos proceder para nossas validações em ambos os provedores ( Meraki e Azure ). Para isso, vamos validar os status logo abaixo:

No Dashboard Meraki podemos também consultar na aba de Logs, conforme abaixo:

Testes executados na Infra

Como efetuamos todas essas configurações, vamos agora consolidar o funcionamento fim-a-fim da solução para garantirmos que está tudo corretamente para nosso usuário final. Para isso, vamos apenas consolidar que nosso segmento de LAN ( MX ) está sendo permitindo para ser roteado por dentro de nossa VPN, ou seja, vemos aqui que somente minha rede 192.168.0.0/24 está liberada.

Segue validação sendo executada através da máquina on-premises.

Segue consolidação sendo feita através da console da Cloud:

Conclusão

De fato após a construção de sua infra na cloud as configurações dentro do ambiente é muito prático e facil de gerenciar. O único ponto que acho ainda crítico que estamos relacionado a trabalhar com IKEv1 e a menção de que não iremos usar um protocolo de roteamento, e somente iremos ficar mencionando quais as redes que deverão trafegar por dentro da VPN.

Isso dificulta no sentido de se você tiver redes novas sendo acrescentadas na LAN Meraki, você necessariamente também irá precisar configurar essa nova rede na cloud.

Cisco Meraki – APIs, como consultar?

Mon, 26 Aug 2019 00:00:00 +0000

Olá Pessoal,

Como vocês já haviam vistos em nosso post anterior e portanto recomendo que você leia ele anteriormente, para que possamos seguir para os próximos passos é de fato consultar nossas APIs e entender o que ela de fato está nos trazendo de informação.

Baseado neste fato, vamos demonstrar para vocês os primeiros passos para que comece interagir via API com seus equipamentos Meraki. Baseado na documentação temos alguns pontos importantes para inserir como variável, tornando assim sua vida um pouco mais fácil nos momentos de executar um ” Get “, “ Post “, ” Put ” e ” Delete “.

Talvez você me pergunte, porque temos esses status para executar as ações via API? Esses termos existem devido a trabalhar com essa metodologia ” Restfull ” ( ixi, acho que agora ele me confundiu mais 🙂 ), entretanto nós já haviamos mencionado isso em outro post de 2017 ( O que é API e Rest API? ). E para ficar ainda mais fácil o entendimento, observe que essas ações estão relacionadas ao funcionamento do HTTP, onde se desejar obter mais informações pode consultar Wikipedia ou propriamente a RFC7231.

Com isso em mente, precisamos agora entender que para conseguirmos obter os dados relacionados a sua organização criada no portal Meraki, precisaremos encontrar além de nossa API Key mais duas informações:

- Organization ID
- Network ID

Como uma dica para que não fique muito extensa sua ” URL ” sendo executada no Postman, é recomendado que você crie uma ” baseURL ” que por consequência ela sempre vai ser a mesma para qualquer solicitação que fizer no dashboard. Segue a variável:

- baseURL = https://dashboard.meraki.com/api/v0

Execução do Postman

Dando sequencia a execução das informações via Postman vamos obter os dados relacionado a nossa segunda variável depois de inserir sua Key API. Para inserir sua KEY recomenda-se criar um ambiente de variáveis para controlar suas requisições ou também controlar varios ambientes com diferentes variáveis. Para criar você deve selecionar Manage Environments -> ADD

Após este passo devemos agora obter nossa segunda variável para continuarmos trabalhando na execução e obter as informações globais para acesso completo as APIs. Neste momento vamos obter as informações relacionadas ao “ OrganizationID “

- Metodo: GET
- URL: https://dashboard.meraki.com/api/v0/organizations

Após essa informação precisamos obter nosso terceiro dado ( variável ) para que de fato possamos dar sequencia a qualquer outra requisição dentro de nossa organização, onde ela vai agora basear-se no ” NetworkID “:

- Metodo: Get
- URL: https://dashboard.meraki.com/api/v0/organizations/{{organizationId}}/networks

Como mencionado anteriormente você pode criar sua ” baseURL ” para inserir em suas variáveis globais, desta forma sua URL no Postman fica mais “ enxuta “, pois esse é o endereço inicial padrão da Meraki.

Com esses dados obtidos todas as outras solicitações ao portal serão baseando-se em algum momento nessas variavéis, tendo URL sendo requisitadas as duas informações simultaneamente ou momentos de apenas uma única variavél.

Espero que vocês tenham gostado 😆 e demos mais um passo para que possamos seguir nossa jornada para programar ações via Ansible em nosso dashboard Meraki.

Qualquer dúvida deixe seus comentários abaixo que vamos compartilhando nosso conhecimento entre todos da comunidade.

Abs,
Rodrigo

Cisco Meraki – Facilidades através de APIs

Tue, 06 Aug 2019 00:00:00 +0000

Olá Pessoal,

Como vocês podem observar hoje vamos explorar um mundo um pouco diferente, o qual vou demonstrar como habilitar o recurso de APIs dentro do portal Meraki, e desta forma ter um mundo gigantesco de oportunidades para trabalhar com os diferentes recursos existentes nesta solução.

Vale ressaltar que neste portal podemos criar ao mesmo tempo duas APIs, ou seja, você pode executar com os mesmo privilegios utilizando uma dessas APIs criadas. Não entraremos nos detalhes relacionado a segurança, mas vale lembrar que essa chave é instrasferível, e a partir do momento que é compartilhada com alguém ela terá total acesso a qualquer funcionalidade de seu portal.

Como Habilitar API no Portal

Após acessar seu portal você deve ir em Organization -> Configure -> Settingse habilitar essa funcionalidade, entretanto vale lembrar que para isso precisaremos garantir que já temos nosso token criado no portal e que assim possamos utilizar em outras ferramentas. Veja abaixo:

Após acessar seu profile como indicado acima, você será redirecionado para avaliar suas ” Keys “, se já tiver sua API, perfeito, entretanto se já tenho esquecido irá precisar ser gerado uma nova, pois o texto não é recuperado para ” copiar e colar “. Veja abaixo minha chave já existente.

Caso não seja visualizado nenhuma, será necessario apenas clicar em ” Generate new API Key ” e logo após ela gera automaticamente conforme abaixo.

Após esse processo você já pode visualizar suas chaves e quando foi a última vez que ela foi utilizada. PS.: Como informado anteriormente podemos ter duas chaves ao mesmo tempo criada.

Após esse processo você pode me perguntar, o quê eu vou fazer com isso?

Bem, poderiamos colocar milhares de opções aqui, mas vou deixar você pensar em alguma e se quiser pode colocar em nossos comentários e assim exploramos opções para discutirmos.

Como usar as APIs

Para que possamos começar a explorar este vasto universo de opções que temos, eu recomendo utilizar a ferramenta denominada Postman, que por sua vez é gratuita, e mesmo na versão ” free ” temos milhares de opções como salvar o histórico das APIs consultadas, criar variáveis de ambiente global ou para suas bibliotecas, criar pastas para registro de todas as APIs para futura validação, etc.

Abaixo você pode conferir a tela inicial e de fato observar minhas ” Collection ” e também os diferentes ” WorkSpace ” que você pode criar para facilitar no seu dia a dia.

Como estamos falando de Meraki você pode consultar facilmente o portal, para pesquisar qual API deseja utilizar, bem como ter uma interatividade em relação qual a resposta que devemos esperar após consultar API desejada em qualquer dashboard Meraki.

Para visualizar acesse o link de APIs Meraki e visualize conforme abaixo. Vale ressaltar que para esse caso você consegue fazer o download de todas as APIs ( pastas + URL ) diretamenta já para seu Postman, basta clicar em ” Run in Postman ” e ele fará todo o download para seu postman instalado. 🙂

Caso você esta tendo algum problema para consultar seus dados, valide seu token bem como se as informações relacionadas a sua organização ( Meraki Dashboard ) é correspondente com aquilo que você esta consultando.

Espero que vocês tenham gostado e deixem seu feedback abaixo, bem como também respondendo sobre nosso questionamento no meio de nosso post. Nos aguarde que iremos mostrar como navegar dentro dessas APIs e mostrar consultas via Ansible.

Abs,
Rodrigo

Cisco Meraki – Captura de Pacotes – Parte 2 – CloudShark

Thu, 30 May 2019 00:00:00 +0000

Olá Pessoal,

Conforme mencionado hoje venho aqui para demonstrar a ultima facilidade adicionada no portal Meraki para captura de pacote. Em nosso ultimo post ficou a menção sobre analise caso você não consiga fazer em sua máquina local devido alguns parâmetros.

Pois bem, como hoje temos muitos serviços em nuvem essa analise não poderia ficar de fora, então existe a facilidade de utilizar o parceiro CloudShark para que possamos integrar as plataformas e analisar via browser. Quer conferir siga o detalhamento!

Implementação

Para fazer sua integração existe a facilidade de criar-se uma conta trial para que você deguste e faça sua analise se vale o $$$ para esse investimento dentro de sua compania. Acesse o site cloudshark.io e faça seu cadastro.

Após esse processo você vai integrar as duas plataforma através de uma ” API Token ” que pode ser capturada no portal conforme abaixo:

Após esse processo você deve guardar essas informações para que possamos inserir posteriormente no Dashboard Meraki.

Com base nessas informações você deve acessar seu portal Meraki através do campo Network Wide -> Configure -> General

Seguir para a funcionalidade de Packet Capture e colocar como ” Enable “, e preencher as informações obtidas anteriormente.

Após esse processo você pode validar na função de ” Packet Capture ” no portal Meraki que você terá uma nova opção para fazer seu stream ( .pcap ) que esta relacionado a sua funcionalidade.

Após finalizar o tempo programado, você pode consultar no seu dashboard CloudShark, que você já irá ver seu ” packet capture “.

Após validar esse arquivo você tem sua captura como se estivesse em seu wireshark, e os filtros funcionam da mesma forma. Obs.: Daqueles que consegui testar até o momento.

Acredito que agora todas as suas dúvidas tenham sanado e de fato temos uma facilidade muito interessante para trabalharmos em nosso dia a dia. O que você achou? Deixe seus comentários.

Abs,
Rodrigo

Cisco Meraki – Captura de pacotes – Easy!!!

Mon, 27 May 2019 00:00:00 +0000

Olá Pessoal,

Como todos sabem eu já tenho vários posts explicando sobre Meraki, e como já faz um tempo que não divulgo nada de Meraki, venho aqui para trazer mais uma facilidade fantástica que podemos usufrir a nosso favor. 🙂 ( sniffer )

Em algum momento você já precisou capturar pacote no switch? no AP? Saída da Internet? Se respondeu sim, em alguma pergunta e também lembrou daquela dificuldade para fazer isso, eu recomendo você me acompanhar nesse post.

Detalhamento

Pois bem, em muitas situações temos que nos aprofundar em nossos troubleshooting para que de fato tenhamos informações concretas e detalhes do porque algumas coisas estão acontecendo ou inverso ( porque não esta acontecendo ). Com isso chegamos naquele ponto, preciso capturar pacotes para ver o que esta passando por essa porta.

Neste ponto você já começa a planejar como você irá executar essa captura:

Vai parar o serviço;
Qual porta vou espelhar;
Vou capturar ingress ou egress;
Vou salvar a captura no device
- Tenho espaço na memória flash;
- Meu servidor tftp esta alcançavel;
- Meu servidor tftp já tem o Wireshark;
  - - Não, vou ter que transferir para minha máquina;
Vou ter que encaminhar para outra pessoa/cliente para analisar
- Arquivo é muito grande, não posso por email
- Vou ter que comprimir…hummm!!!
- Vou ter que subir para a cloud para ele fazer download

Aplicação

Para esses casos vou mostrar para você como é fácil executar essa tarefa dentro da estrutura Meraki, pois como vocês sabem os serviços são baseados em nuvem, assim podemos obter informações rapidamente. Segue a forma padrão para capturar os pacotes indo através do menu Network Wide -> Packet Capture

Após esse processo iremos avaliar, como abaixo, qual device iremos capturar os pacotes, qual interface que desejamos, e se vamos olhar a captura no proprio dashboard ou se iremos fazer o download ( .pcap ) para analisar em nossa máquina, o tempo que essa captura vai durar, qual o nível detalhe da captura ( isso depende do que você quer analisar ), ignorar pacote que não seja revelante e um filtro com expressão ( como o filter do wireshark ).

Até o momento com certeza obtive algumas facilidades e consegui executar ações rápidas para obter as informações, entretanto se o cliente esta na porta 7 do SW1, como podemos fazer?

Você pode procurar pelo cliente cadastrado, MAC-Address ou via a porta do switch. Segue alguns passos para que você possa identificar o cliente e já solicitar captura rapidamente.

Mas ainda você pode me perguntar e se eu não tiver instalado Wireshark na minha máquina ou precisar enviar o arquivo para outro engenheiro ou cliente. Tenho que dizer que existe uma solução.

Entretanto, isso será para nosso próximo post. Fique ligado e nos acompanhe!!!

Espero que vocês tenham gostado e tenha ajudado de alguma forma a fazer essas tratativas dentro da plataforma.

Abs,
Rodrigo

Cisco Meraki – Configuração SNMP – Parte 2

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

Olá comunidade,

Como exposto em nosso post anterior, vamos seguir mais um passo para que vocês possam interpretar sobre as definições de SNMP em nosso dashboard Meraki.

Abaixo segue a configuração para que possamos receber os alertas e obviamente serem logados para futuras analises ou ações reativas/preventivas para seu ambiente. Como exposto anteriormente, somente poderemos configurar esse campo com um endereço público e definindo a porta do SNMP, para que neste exemplo foi definido como 162.

Vale ressaltar sobre a menção das portas do SNMP na qual trabalhamos com 161 e 162, tendo assim como especificação a 162 sendo a porta de envio dos traps, ou seja, pelo exposto acima meu servidor irá receber as mensagens via a porta definida.

Talvez você pense em relação a segurança e com certeza é algo que devemos nos preocupar. Pois bem, pensando nisso você pode executar a validação e identificar através do Dashboard ( como explicado neste post ) sobre as configurações do Firewall. Para detalhar segue abaixo as origens ( source ) que irão encaminhar os ” traps ” para seu servidor.

Pois bem, abaixo executo uma regra ” Port forwarding ” para que qualquer solicitação na porta mencionada, ela seja re-direcionada para meu IP privado. PS.: Neste caso estou usando porta padrão na perspectiva do ambiente público para este teste, porém como uma preocupação você também poderia mudar essa porta.

Enfim, após todo esse processo você precisa incluir nas definições de seu Dashboard ( Network Wide -> Alerts ) quais alertas serão direcionados para seu ambiente de monitoração. Para isso existe um acrônimo padrão definido como sendo ” snmp “. Segue abaixo um exemplo:

Após essa definição podemos ver em nossa ferramenta de testes os logs sendo populados diretamente no meu servidor. BINGO!!!

Vale lembrar que esse logs muitas da vezes precisam ser tratados pelas ferramentas de gerência, ou vocês trabalharem para que isso seja concatenado de alguma forma, com o intuito de ser melhor visualizado por qualquer pessoa que de fato não tenha um total conhecimento.

Espero que vocês tenham gostado e deixem seus comentários se algo não ficou muito claro nas configurações ou definições desses recursos.

Abs,
Rodrigo

Cisco Meraki – Configuração do SNMP

Mon, 21 Jan 2019 00:00:00 +0000

Olá Pessoal,

Conforme eu havia prometido, precisamos fazer nossas validações relacionadas ao SNMP, bem como a maneira que vamos habilitar esse serviço em nosso Dashboard. Então segue comigo!!!

Para que possamos habilitar o SNMP devemos acessar nosso dasboard e habilitar através de Organization -> Settings -> SNMP

Como mencionado acima estamos habilitando inicialmente a versão 2, apenas para esclarecer o campo de ” Download ” na figura cima, esta relacionado em fazer o download das ” MIBs – Cloud Meraki ” para que você instale em seu servidor de gerência e possa fazer as consultas no ” Dashboard ” e não seria as MIBs dos equipamentos instalados em sua organização. Em relação aos IPs restritos esta relacionado para que você controle as origens que irão fazer as consultas para os devices, pois se pensarmos em trabalhar com V2 as mensagens são encaminhandas em ” clear text “, portanto são medidas de segurança que podem ser adquiridas.

Após isso devemos configurar nossa community, onde devemos ir Network Wide -> General -> SNMP

Vale ressaltar que o acesso SNMP da Meraki apenas suporta requisições ” get “, então nenhuma alteração na configuração do Dashboard pode ser feita usando SNMP. A Meraki usa somente ” community ” para leitura.

Para que possamos fazer algumas validações vamos instalar no Ubuntu a biblioteca de SNMP para capturar alguns logs. Segue abaixo o pacote para instalação no Ubuntu:

sudo apt-get install snmp

Se você deseja colocar no Windows existe uma ferramenta bem simples chamada SNMPWalk, onde é totalmente free e pode ser feito download no site da Solarwinds.

No comando abaixo estou fazendo uma consulta diretamente para o IP de um equipamento na minha estrutura, para qual eu gerencio através do endereço ( 192.168.0.15 ) + especificando a porta. Após esse processo vou obter uma lista gigante de todos os ” OIDs ” desse equipamento, assim consigo garantir que meu serviço de SNMP configurado no meu ” Dashboard ” está funcionando corretamente.

Se desejar, pode fazer especificamente em um “ OID ” e validar que de fato está correspondendo a consulta anterior:

Até o momento vimos que nosso serviço esta habilitado e operacional, entretanto muito de vocês devem estar perguntando. OK, mas como vou receber os “ traps ” para que eu tenha uma gerência reativa dos equipamentos?

Neste caso temos que seguir através de um novo recurso que de fato ele não fica habilitado por ” default ” em nosso dashboard. Para solicitar essa demanda devemos abrir um “ ticket ” com o pessoal de suporte da Meraki, para que seja visto esse recurso. Abaixo mostro como abrir um chamado diretamente de nosso ” Dashboard “.

Posso declarar que o atendimento foi bem rapido, até porque é um chamado muito simples. 🙂

Após a confirmação, podemos observar abaixo o novo recurso operacional e os campos para que possamos configurar. Isso pode ser visualizado através do Network-Wide -> Alerts -> SNMP

Como explicado acima o servidor que irá receber esses alertas somente pode ser configurado através de um endereço público, isso deve-se pois os alertas são gerados através do ” Dashboard “, consequentemente está atrelado com as menções de download das ” MIBs ” para seu servidor de gerência.

Em nosso próximo post, vou demonstrar sobre esses alertas em uma ferramenta. 🙂

Espero que vocês tenham gostado e aguardo seus comentários.

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

Cisco Meraki – Qualidade de Serviço – parte 1

Wed, 26 Dec 2018 00:00:00 +0000

Olá Pessoal,

Como vocês podem ter visualizado no título, venho aqui hoje para trazer um pouco do conceito de configuração de QoS ( Qualidade de Serviço ) para dentro de nossa infra-estrutura Meraki.

Em nossos posts eu não vou entrar no detalhe sobre os conceitos de QoS e como isso é aplicado para determinada aplicação, porém se deseja saber um pouco mais recomendo você olhar alguns de nossos posts sobre QoS.

Como já venho mostrando em nossos posts de Meraki, a ideia do produto e trazer de maneira simples alguns ítens que de fato gastamos um esforço gigante para implementar em nossos ambientes, desta forma para que você entenda vou iniciar falando sobre as configurações nos switches.

Neste equipamento ( MS220 ) a unica demanda que existe para as configurações estão relacionadas como sendo a confiança da marcação que esta relacionado outro device conectado a porta ( ex.: Access Point, Phone ), ou você forçar a marcação baseado naquela demanda para qual aquela VLAN representa dentro de sua infra-estrutura.

Segue abaixo a configuração nesse exemplo, onde ela pode ser acessada através ( Switch -> Switch Settings ):

Como vocês podem observar eu deixei definido 3 VLANs, para qual eu possuo as 3 opções conforme mencionado acima. Para que vocês possam entender, vou fazer uma validação baseado na VLAN15 que de fato, está correlacionado ao que meu switch esta executando independente do meu end-point connectado a esse switch. Lembrando-se que obviamente este endpoint pertence a essa VLAN15.

Como podem observar estou garantindo que meu trafego relacionado a esta VLAN15 está marcando meu trafego em AF41, ou seja, todo ” inbound ” será classificado desta forma, porém o retorno do meu pacote não tem minha marcação devido à não ter ” outbound ” como regra valendo-se do conceito de QoS ( Fim a Fim ) minha ponta remota teria que garantir que teremos a mesma marcação.

Talvez vocês possam se perguntar. Ok, e a questão de confiança ” Trust ” baseado na VLAN5? Pois bem, nesse caso tenho um teste que conectado ao meu switch existe um “ Access Point “, que por consequência vou fazer com que via meu endpoint essa consulta ao ambiente, para qual esse device ( WIFI + VLAN 5 + SSID ) tem match com a classe de serviço ( Spotify ) e a mesma seja marcada com AF31.

Portanto, se olharmos nossa figura abaixo o ” packet capture ” foi executado no meu switch, dedicado a porta que meu ” Access Point ” esta conectado.

Com isso vocês podem observar que meu switch apenas esta confiando na marcação que o meu ” Access point ” esta encaminhando nesta porta, não fazendo nenhuma remarcação. Talvez, agora vocês me perguntem. Porque agora ambos ( request / reply ) estão sendo marcados?

Neste caso para essa aplicação eu tenho essa marcação, pois como comentei estou fazendo essa classificação em meu equipamento de borda ( UTM – MX64 ), que por consequencia ele vai entregar também para meu ” Access-Point ” classificado e marcado.

Espero que vocês tenham gostado e o nosso proximo post vou trazer as menções dessas configurações na perspectiva do meu ” Access-point “. 🙂

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 Meraki – Habilitar 2FA para Dashboard

Thu, 16 Aug 2018 00:00:00 +0000

Olá Pessoal,

Já faz um tempo que não trago nenhum tópico sobre Meraki, portanto hoje resolvi publicar um ítem rápido mas que baseando-se nas demandas de segurança que temos hoje acaba-se tornando muito importante, principalmente se em algum momento você vai oferecer um acesso restrito ao seu cliente através do dashboard.

Enfim, hoje existem muitas demandas para garantirmos o acesso, que seja específico e identificado de fato por aquele usuário acessando o site / app, onde seja desafiado em diferentes formas, porém mesmo assim estamos sujeitos a diferentes formas de capturas de senhas. Com isso diversos sites hoje oferecem autenticação chamada de 2FA ( Two Factor Authentication ), porém nem tudo são ” flores “, pois sites que oferecem o recurso via SMS já sabemos que não é confiável e tem suas vulnerabilidades, desta forma o mais correto até o presente momento é você trabalhar com autenticação sendo garantida através de um APP. Porém, como dica aconselho não utilizar o ” Google Authenticator ” e recomendaria uma solução open-source e de maior confiança que seria o ” Authy “.

Você pode fazer uma validação no site Two Factor Auth List, para avaliar se seu site / app tem essa disponibilidade, ou até mesmo fazer publicações para exigir que as empresas tomem as providências para liberar esses recursos fazendo desta forma um mundo interconectado com maior segurança. Baseado nessas informações você já pode avaliar alguns ítens se de fato seus dados estão sendo cuidados com respeito. 🙂

Bom vamos ao ponto que é de fato mostrar como habilitar. Devemos seguir para nosso menu Organization -> Configure -> Settings.

Essa demanda pode ser habilitada de duas formas para receber, como SMS ou registrar via APP. Após esses passos você precisa sincronizar com seu app e utiliza-los desta forma. Inicialmente esse acesso permanece da mesma forma, porém terá uma janela adicional para inserir seus códigos.

Desta forma você já esta garantido de alguns acessos indevidos ou preocupado com seu usuario/password que não estão sendo capturados para futuros logins. Nesta pagina demonstrada anteriormente, você pode melhorar suas questões de segurança, habilitando ” timeout “, ” Lockout account “, etc

Espero que tenham gostado e que vocês possam também pensar nas questões de segurança. 🙂

Abs,

Rodrigo

Cisco Meraki – Clientes Bluetooth

Thu, 21 Jun 2018 00:00:00 +0000

Olá Pessoal,

Voltando para nossos tópicos de Meraki, hoje gostaria de trazer algumas facilidades que podemos obter para identificar via ” Access Point ” nossos clientes bluetooth.

Obviamente, para que isso ocorra seu equipamento precisa suportar essa demanda, porém se olharmos os modelos de AP da Meraki, podemos observar que praticamente quase todos os modelos já tem essa funcionalidade, com excessão apenas do MR20 e o MR70.

Hoje as funcionalidades de Bluethooth podem ser utilizadas para outras características dentro de algumas soluções, com o intuito de observar o comportamento de algum usuário, rastreabilidade desses elementos dentro de algum espaço para capturar comportamentos e até fazer notificação via ” push ” e ” pull ” por alguma aplicação desenvolvida e que possa avisar seus usuários no momento que eles entram em algum estabelecimento. Essas demandas devem ser tratadas através dos “ beacons ” e gerenciadas através das ” UUIDs ” o qual será gerada pelo proprio portal da Meraki. Para ativar a funcionalidade devemos seguir para Wireless -> Bluetooth Settings, conforme abaixo, porém não vou detalhar muito sobre UUIDs devido a não conseguir emular nesse momento para vocês.

A partir desse momento seus APs irão iniciar o escaneamento procurando esses elementos dentro de seu alcance, para que ele possa popular e informar os ativos que estão com o bluetooth ativado. Para que possamos verificar esses clientes devemos selecionar no equipamento em Wireless -> Bluethooth. Após isso, podemos observar abaixo os elementos.

Após selecionar elemento você pode criar algumas politicas relacionado aos alertas, no momento que ele entra no seu alcance e quando ele sai de seu alcance. Essas notificações são executadas através de um e-mail para o administrador da conta.

Após selecionar ” Edit Alerts ” você pode selecionar as notificações.

Para ter um detalhamento maior sobre os “ scanning ” das APIs para o Bluetooth recomendo visualizar essa documentação Meraki para entender um pouco melhor, se por acaso você deseja analisar isso dentro de seu ambiente.

Em nosso proximo post vou detalhar um pouco sobre o escanamento via APIs para identificar os usuarios de WIFI e montar nosso mapa de “ heatmap “.

Abs,
Rodrigo

Cisco Meraki – Air Marshal – Segurança WIFI

Mon, 21 May 2018 00:00:00 +0000

Olá Pessoal,

Vamos seguir com nosso tutorial explicando as funcionalidades que temos nos equipamentos Meraki. Hoje venho aqui para falar um pouco sobre opção oferecida através dos Access-Points, que por sua vez é chamado de Air-Marshal.

Como todos sabem, hoje nosso ambiente de WI-FI também é um item muito importante dentro de nossa infra-estrutura e obviamente ele acaba se tornando um objeto desejado para utiliza-lo como uma porta de entrada, observando no sentido de segurança. Desta forma, neste ítem é sempre interessante você analisar de que forma irá gerenciar essa infra-estrutura, pois temos diversos Access-Points de mercado, que definitivamente não temos os controles necessários para evitar alguns abusos.

Nesse caso, modelo que estou demonstrando efetivamente possue 1 radio dedicado apenas para fazer esse monitoramento, o qual faz o escaneamento do ambiente, analisa interferência, faz tratamento de ” Rogue APs “, o qual pertence as caracteristicas conhecida como WIPS ( Wireless Intrusion Prevention System ). Desta forma, ele oferece uma flexibilidade para o ambiente, pois nenhuma dessas caracteristicas irá impactar ao cliente no sentido de utilização/processamento do AP, pois são rádios isolados e processamento separado. Vale lembrar, que isso é feito para as duas frequências oferecidas 2.4GHz e 5GHz.

Segue abaixo, um exemplo sobre a menção das prevenções que podemos executar tendo como a conectividade sendo executada via WIFI.

Tendo isso como base a grande facilidade aqui exposta é justamente habilitar essa funcionalidade nos APs e analisar o que de fato está sendo observado dentro de nosso ambiente. Para isso devemos ir em nosso Menu -> Wireless -> Air-Marshal

Após esse acesso iremos para tela principal de onde iremos visualizar os APs que estão trabalhando com essa funcionalidade, bem como outras funções que irei explicar mais abaixo:

Como podem observar enumerei 3 ítens:

Quantos APs estão fazendo o escaneamento dentro de sua infra-estrutura
Por padrão essa opção ( Allow clients to connect to rogue SSIDs by default ) vem habilitada para liberar os usuarios a fazerem autenticação em ” Rogue SSIDs “, devido a isso vamos habilitar para que possamos bloquear, evitando assim que nossos clientes autentique nesses APs falsos.
Diversas opções para que você coloque SSIDs em blacklist ou whitelist, bem como nesse meu exemplo coloquei para que eu receba uma notificação caso tenha um ” match ” com meu SSID.

Após esse detalhamento podemos observar todos os SSIDs que estão sendo visualizados pelo seu AP e desta forma identificar através de diversos campos as informações, neste exemplo observei um SSID em especifico e o mesmo pode me trazer informações adicionais sobre ele como vendor, canais, encriptação, etc.\

Após isso eu apenas habilitei meu celular para trabalhar como um roteador e ao mesmo tempo meu AP, detectou que existe alguém na rede fazendo ” spoof ” desse SSID, para qual ele detalha onde isso foi detectado ( Localização do AP ), bem como MAC Address e a potência ( dB ), trazendo a percepção se esse elemento o quão próximo esta desse meu AP.

Para esse caso vale lembrar que ele não irá evitar que seu cliente associe-se a esse ” spoof ” AP, pois ele esta fora de sua rede, no sentido que ele não é um AP conectado diretamente em sua LAN e sim algo fazendo broadcast utilizando o mesmo SSID. Com isso, o cliente que estiver mais proximo desse “ spoof “, ou seja, o sinal mais forte e obviamente se ele tiver todas as credenciais para autenticar seu usuário, ele irá autenticar, ou se não deveria isso pode ser uma brecha de segurança, na qual você não criou alguns passos de validação do usuario. Nesse campo você pode ter sempre os SSIDs sendo detectado como “ spoof “, pois se tiver mais APs instalados no ambiente usando o mesmo SSID ele será identificado como “spoof “, mas não que seja algo intrusivo em sua infra-estrutura. Segue abaixo apenas demonstrando que meu endpoint pegou um endereço IP baseado na faixa que deixei no meu celular ( trabalhando como um router ).

No proximo passo vou simular a situação onde tenho um AP conectado em minha infra-estrutura ( conectado no switch ), para qual ele vai ser detectado como um ” Rogue AP “. Após ligar meu Rogue AP, conectar na porta, automaticamente meu AP ” legitimo ” detectou que existe algum intruso na rede oferecendo conectividade, que consequentemente não é permitido. Veja figura abaixo para detalhar:

Você pode observar o detalhamento do evento sendo evidenciando, na qual gostaria de mostrar que no passo ( 1 ), podemos visualizar que ” Rogue AP ” foi visto na LAN e ao mesmo tempo ele está ” contained “, que defini que meu Air-Marshal ( AP legitimo ) esta detectando algo intruso na rede e vai fazer com que os clientes não sejam associados a esse AP falso, colocando a messagem ” Deauthentication ” no pacote para que os cliente drope essa conexão e permaneça autenticado em nosso AP legitimo.

Após isso, podemos visualizar no passo ( 2 ) que podemos ter maiores detalhes desse equipamento, bem como já observando nosso endereço MAC ( BSSID ). Para o passo seguinte ( 3 ), executei mais um teste criando novamente um novo SSID e definindo uma autenticação, que ao mesmo tempo vocês podem observar no log que ele identificou essa criação ( TESTE_1 ).

Logo em seguida, para consolidar essa notificação/evento podemos receber automaticamente um e-mail notificando que foi identificado um ” Rogue AP ” em nossa infra-estrutura. Segue abaixo o e-mail de exemplo:

Com isso, vocês podem observar a facilidade que temos em nossas mãos para gerenciar nosso ambiente e garantir segurança em nossa infra-estrutura. O que vocês acharam dessa facilidade apresentada? Já tiveram dor de cabeça em relação a esses problemas?

Deixe seus comentários!!! 😛

Abs,
Rodrigo

Cisco Meraki – Regras do Firewall para Acesso a Cloud Meraki

Fri, 27 Apr 2018 00:00:00 +0000

Olá Pessoal,

Como vocês vem acompanhando nossos posts sobre Meraki, e conforme nossas explicações os equipamentos são gerenciados através da Cloud, devido a este parâmetro temos o principio que os equipamentos instalados na sua infra-estrutura precisam acessar ao ambiente público para alcançar o destino, desta forma serão geridos por essa estrutura de Cloud.

Devido a isso, algumas pessoas me perguntam como controlar ou o que liberar dentro de minha infra para que esses equipamentos sejam geridos conforme a demanda do produto. Bom, a resposta é simples, pois temos todas as regras já declaradas para serem aplicadas internamente e obviamente você pode garantir sua politica de segurança conforme os acordos executados internamente dentro da empresa.

Para você obter as regras é necessario acessar o menu principal, clicar em Help ( 1 ), após isso Firewall Info ( 2 ). Veja abaixo:

Após esse processo você pode visualizar as regras que deve ser implementadas, bem como se desejar pode fazer o download, conforme abaixo:

Espero que isso possa responder alguns questionamentos que eu havia recebido e ainda não havia publicado para todos.

Abs,
Rodrigo

Cisco Meraki – RF Spectrum

Mon, 09 Apr 2018 00:00:00 +0000

Olá Pessoal,

Dando sequência ao nossos posts e trazendo como sendo mais uma facilidade dentro de nossa estrutura sobre o assunto Wireless, hoje venho para detalhar um pouco sobre esse recurso disponível no Portal Meraki, chamado de RF Spectrum ( Espectro de Frequência ).

Os access points Meraki tem uma funcionalidade denonimada como WIPS ( Wireless Intrusion Prevention System ), que irei tratar sobre esse assunto em um outro post detalhando sobre o Air Marshal.

Acredito que vocês observaram em nosso primeiro post que estou mostrando baseando-se em nosso modelo MR33, para qual ele contém 3 radios distintos, na qual o 3 radio está relacionado ao item mencionado anteriormente ( Air Mashal ). Pra que possamos acessar esses recurso de espectro devemos ir em Wireless -> RF Spectrum.

Nessa tela já podemos observar os canais que estão sendo utilizado pelos seus access points, bem como a utilização para as frequências de 2,4GHz e de 5GHz.

Neste modelo os endpoints que tenho conectado dentro do meu segmento não tem a funcionalidade de trabalhar com 802.11n e 802.11ac, devido a isso podemos observar somente a utilização em nosso canal de 2.4GHz.

Após consolidar essas informações podemos agora verificar nosso espectro de frequencia e analisar onde temos maior ” poluição ” em nosso sinal, ou seja, endpoints que estão gerando interferências nessas frequencias ( outros APs, telefone sem fio, microondas, etc ).

No primeiro momento vamos observar o sinal na frequencia de 2.4GHz.

Após essa validação já conseguimos concluir que a maior ” poluição ” ( interferência ) está entre os canais de 3 a 6, devido a isso nosso AP ( access point ) escolheu trabalhar no canal 1, obviamente isso ocorreu porque deixamos habilitado para que ele escolha isso dinamicamente e altere esse canal, pois as interferências podem alterar e um determinado momento será mais interessante ficar no canal 6 ou 11. Tradicionalmente, quando estamos trabalhando na frequência de 2.4GHz os canais mais indicados para configurar em nossos equipamentos é 1, 6 ou 11, isso se deve a faixa de frequência, como visto abaixo.

Devido ao nosso AP ter a funcionalidade de 5GHz podemos ter uma outra percepção de como neste sinal temos resultados totalmente opostos em relação interferência, pois temos menos equipamentos que estão concorrendo dentro desse espectro de frequência. Logo abaixo temos as informações relacionadas:

Desta forma temos a informação da utilização no canal 157 e quase nenhuma influência de outros equipamentos nesse espectro de frequência, vale ressaltar sobre a segmentação das faixas de frequência para esse exemplo, bem como mencionar que aqui estou demonstrando o 5GHz em um plano pegando como o Estados Unidos, devido ao meu gráfico estar demonstrado esses canais, que são atendidos pelo termos de UNII-1 (5.150 to 5.250 GHz) e UNII-3 (5.725-5.825). Segue o gráfico:

Após isso, ainda temos a visibilidade por faixa ( 2.4GHz e 5GHz ) como está utilização por canais e quais são os APs que estão interferindo nesse espectro. Vou apresentar aqui somente a utilização da faixa de 2.4GHz.

Você deve-se lembrar que havia comentado que o AP faz por padrão a seleção de seu canal automático, entretanto existe opção de você colocar manualmente esse canal, o que acaba não sendo muito interessante desde que você tenha um controle mais rigido dentro de sua estrutura para trabalhar manualmente selecionando esses canais, ou de você já ter feito todo seu trabalho de site survey e já definido as células que vão trabalhar em cada canal, não tendo a interferência em seus demais APs. Para isso é possivel fazer alteração em Wireless – Radio Settings e selecionando ( item 1 ) qual a faixa que deseja alterar e através do canal ( item 2 ) selecionar qual o canal desejado para esse AP. Segue o exemplo abaixo:

Enfim, aqui encerro o tópico sobre espectro disponível para analise automaticamente pelo Dashboard da ferramenta. Espero que você tenha gostado e deixe seu comentário abaixo o que esta achando dessa serie. 😉

Em nosso próximo post vou mencionar sobre Air Marshal com a tratativa baseado em rogue APs e spoofs.

Abs,
Rodrigo

Cisco Meraki – Wireless – Site Survey

Thu, 22 Mar 2018 00:00:00 +0000

Olá Pessoal,

Dando sequência em nossa serie sobre Meraki ( quem não acompanhou pode conferir aqui ), vamos hoje falar sobre uma facilidade que a ferramenta nos proporciona que chamamos de Site Survey.

O que é um Site Survey? Podemos consultar no Wikipedia, porém posso mencionar para vocês que esse termo é muito utilizado no dia a dia de quem trabalha com Wireless, pois ele está atrelado especificamente ao ambiente que irá ser atendido por uma rede sem fio. Em resumo, o termo traz o conceito de encontrar ou inspecionar uma área onde o trabalho executado por aqueles usuários devem ser atendidos, bem como trazer uma perspectiva mais detalhada sobre os pontos que devem ser colocados nossos Access Points ( Pontos de Acesso ) em nossa infra-estrutura dando informações sobre distância, throughput, interferências, potência das antenas, etc.

Nesse caso, coloco aqui um exemplo de umas telas relacionado uma ferramenta que pode ser conhecida por alguns, chamada Ekahau, onde traz muitas facilidades nessas questões de site survey e também já executa o relatório com todas as informações. Vale lembrar que aqui é um exemplo e outras ferramentas free nos já temos no mercado, porém nesse exemplo ( Ekahau ) existe um licenciamento.

Podemos também conferir uma documentação que a própria Cisco disponibiliza trazendo dicas de como podemos executar nosso site survey em ambiente WLAN.

Vocês podem perguntar, e o Meraki?

Como venho demonstrando nesses posts, a ideologia desse produto é trazer facilidade, então podemos considerar que existe um item nativo da solução que não irá trazer algo especifico/detalhado de um relatório como mencionado através de uma ferramenta específica para esse conceito, mas podemos considerar que com esse exemplo podemos de alguma forma já oferecer um resumo de quais pontos serão instalados os pontos de acesso e as bandas/throughput/potência do sinal que teremos nos locais.

Para oferecer essa facilidade podemos de fato fazer como o tradicional, acessar via browser o endereço do default gateway que estamos capturando pela conectividade WI-FI e acessar essas informações, mas para que não tenhamos que analisar qual IP esta definido para essa rede, podemos utilizar um nome em comum e que posteriomente ele irá fazer a resolução do nome ( DNS ).

Para habilitar essa funcionalidade devemos navegar através Network-Wide -> General e habilitar a funcionalidade conforme demonstrado abaixo:

Como podem observar existem diversas formas de acessar o equipamento para fazer validação através dos nomes mencionados, porém o mais comum para utilizar é my.meraki.com ou setup.meraki.com. Se o acesso por nome ( DNS ) não for possível, a página de status local também será acessível pelo endereço IP. Isso geralmente é útil ao configurar inicialmente o dispositivo em uma rede sem estar habilitado o DHCP ou ao definir a configuração IP de um dispositivo antes da implantação.

Caso isso ocorra você pode fazer o acesso desta forma:

**MR –**10.128.128.126
Para acessar esse endereço, configure um dispositivo com as seguintes configurações de IP e, em seguida, procure o endereço em um navegador da web.
Endereço IP: 10.128.128.125
Máscara de sub-rede: 255.255.255.0
MS – 1.1.1.100
Para acessar esse endereço, configure um dispositivo com as seguintes configurações de IP e, em seguida, procure o endereço em um navegador da web.
Endereço IP: 1.1.1.99
Máscara de sub-rede: 255.255.255.0
Nota: Alguns modelo de switches MS têm uma porta de gerenciamento dedicada que pode ser usada sem a necessidade de definir um IP estático em seu cliente.
MX e Z1/Z3 – Pode variar
A maioria dos modelos MX tem uma porta de gerenciamento dedicada usada para acessar a página de status local. Caso contrário, a página de status local estará acessível no endereço IP da LAN do MX ou Z1/Z3. Por padrão, os dispositivos MX e Z1/Z3 executam o DHCP. Quando o cliente estiver conectado a uma interface de LAN do MX ou Z1/Z3, localize o endereço IP e o gateway padrão do cliente. Em seguida, abra o endereço do gateway padrão em um navegador da web.

Depois dessa validação, podemos agora observar o exemplo de conectividade Wireless, capturando as informações através de um cliente conectado ao ambiente.

Essa porcentagem demostrada é justamente referenciando ao que meu cliente está utilizando no momento do teste. Agora outro exemplo demostrando o sinal e o throughput adquirido no teste.

Como mencionei anteriormente estas informações não podem definir uma documentação de um site survey, porém você tem um embassamento mais rápido para o que de fato pode estar impactando na performance daquele usuário em uma determinada área e avaliar a necessidade de fututos pontos de acesso nessa área. Outros ítens também pode ser validados em determinar por exemplo um host conectado via cabo em que porta ele está fisicamente.

Espero que vocês tenham gostado e que isso possa ajudar a você identificar alguns casos que ocorrem em nosso dia a dia.

Abs,
Rodrigo

Cisco Meraki – Atualização dos Equipamentos – SO

Mon, 26 Feb 2018 00:00:00 +0000

Olá Pessoal,

Conforme mencionado hoje vamos falar um pouco de alguns ítens técnicos relacionados aos equipamentos Meraki. Acredito que todos em algum momento já tiveram que executar atualização do SO ( Sistema Operacional ), mais conhecido como IOS nos equipamentos Cisco. Pois bem, como foi sua experiência?

Vamos iniciar algumas discussões em relação ao IOS, e obviamente algumas reflexões podemos colocar abaixo:

Qual versão devo instalar?
Tenho espaço em memoria flash?
Qual procedimento para executar atualização do SO?
Como manter atualizado ( SO ) minha infra-estrutura de todos os equipamentos?
Como gerenciar as versões que tenho em campo?
Preciso ter alguém no local para executar o procedimento?
Quanto esse serviço de técnico em campo custa ( $$ )?

Enfim, pode ser que vocês pensem em mais algum questionamento em relação ao ítem proposto, como sendo atualização de SO. Desta forma, gostaria de mostrar os passos para que você faça todos esses procedimentos nos equipamentos Meraki, que vale lembrar é feito pelo Dashboard ( Cloud ).

No primeiro momento gostaria demonstrar que temos uma opção onde é possível tomar algumas decisões em relação atualização dos equipamentos, que seria visualizar os firmware beta, agendar uma janela de atualização, quais plataformas eu desejo atualizar. Para isso podemos fazer acessando o menu Network-Wide -> General e scroll down até Firware Upgrades.

Após essa verificação podemos avaliar nossa infra-estrutura e identificar qual a ultima versão que estamos utilizando e consolidar se temos algum upgrade disponível ( Beta ou Stable Release ) para os equipamentos. Para isso podemos ir em Organization -> Firmware Upgrades -> All Networks

Como visualizado temos atualizações para os 3 equipamentos de meu HOMELAB, com isso vou demonstrar que através desse caminho podemos selecionar dois equipamentos e agendar uma janela de manutenção que mais se adequa a sua necessidade.

Devemos agora selecionar Schedule Upgrade.

Devido a estar demonstrando a execução de atualização eu não coloquei horario de janela e acabei de fato solicitando para que fosse executado no mesmo momento.

Com isso, agora podemos observar que conseguimos agendar atualização e de fato qual horario será executado essa atualização.

Baseado nesses fatos podemos consultar agora nos equipamentos através dos menus de cada plataforma ( Security Appliance -> Appliance Status ) e com isso visualizar que os modelos selecionados irão mostrar essa mensagem até o dia e horario que será executado sua janela de manutenção.

Vale lembrar que não tem mágica em relação alguns equipamentos ( Access Point ) na qual ele teve um reload para consolidar sua atualização de Firmware, porém para os outros devices foi executado sem nenhum reload e pela validação não tive nenhum outage em relação ao ambiente ( acesso Internet ) no momento de atualização. Claro, que dentro de um ambiente de produção não podemos arriscar, pois ainda temos um risco de termos algumas falhas ou necessidade de executar um ” Rollback “.

Após execução e atualização dos equipamentos podemos avaliar que agora estamos com as versões mais atualizadas.

Como mencionado sobre ” Rollback “, temos essa opção muito fácil para que após alguns testes no ambiente e de alguma forma seja identificado que temos problemas devido essa atualização podemos voltar a nossa opção de Organization -> Firmware Upgrades e solicitar para que seja feito o processo inverso ( voltar o Firmware anterior )

Talvez você esteja se perguntando onde posso identificar quais são os recursos que sofreram atualização, bem como os ” BUG Fixes ” para de fato decidir se devo atualizar meus equipamentos ou espero uma proxima Release.

Isso pode ser consultado rapidamente pelo proprio Dashboard e analisar quais ” CVE-xxxx-xxx ” estão sendo tratados.

Espero que vocês tenham percebido algumas facilidades que temos para essa solução e obviamente eu ter respondido todos os tópicos que acabei levantando no ínicio de nosso post.

Enfim, o que vocês acharam sobre esse recurso? Traz problemas? Traz facilidades?

Nos vemos em nosso próximo post, explicando mais recursos e implementações para esses ambientes. 😀

Abs,
Rodrigo

Cisco Meraki – Empresa e Comunidade

Fri, 09 Feb 2018 00:00:00 +0000

Olá Pessoal,

Como vocês viram no post anterior sobre CMNA, hoje venho aqui para falar um pouco de como surgiu a empresa e de fato os caminhos que temos dentro das comunidades para obter as informações relacionado as facilidades e obviamente alguns problemas de como pode ser resolvido ou em alguma situação onde ele não pode ser resolvido ( rsrs ).

Vocês devem ter percebido que o principal proposito da empresa é oferecer todas as facilidades ( configuração, gerencia, status, etc ) através da nuvem ” cloud “. Desta forma, é uma empresa de TI gerenciada em nuvem com sede em San Francisco, Califórnia. Suas soluções incluem wireless, switching, segurança, EMM ( Enterprise Mobility Management ), comunicações ( VOIP ) e câmeras de segurança, todas gerenciadas centralmente a partir da web. A Meraki foi adquirida pela Cisco Systems em dezembro de 2012 por 1.2 bilhões de dólares, e como toda aquisição a Meraki era uma startup que surgiu em 2006 criada por 2 estudantes do MIT (PHDs) Sanjit Biswas e Jhon Bicket, através de um projeto chamado ” Free the Net campaing ” que colocava alguns access-points e repetidores ao redor de um bairro (Lower Haight) oferencendo internet de graça em São Francisco.

Hoje em dia ela possuí mais de 230,000 clientes e chegou em 23 Maio de 2017 a 1 milhão dispositivos conectados ( a informação mais atual que eu tenho ), porém já deve ter aumentado observando a data informada. Segue uma imagem divulgada quando eles chegaram nessa marca.

Vocês poderiam se perguntar, mas a Cisco já não tem solução Wireless, Segurança? Sim, porém o proposito nesse formato de negocio é trazer um produto um pouco mais acessível/fácil e que de fato vai atender as demandas em crescimento de ofertas de serviço em nuvem, além do que podemos considerar esses ítens para um mercado de SMB ( Small Bussiness ).

Dentro dessa filosofia coloco aqui alguns canais disponibilizados para que vocês possam participar ou acompanhar dentro da comunidade, discutindo as facilidades e frustrações que podemos vivenciar em nosso dia a dia. Bem provavel em algum momento próximo você poderá estar implementando essa solução ou prestando suporte.

Com isso temos o canal dentro do Reddit Meraki, bem como também da Comunidade Meraki ( nesse caso para acessar você terá que ter seu CSCO registrado na Cisco ). Muitas pessoas me perguntaram como acessar o portal de partner para avaliar se de fato você poderia fazer a certificação, com isso divulgo aqui o Meraki Partners ou também podem seguir pelo Twitter Meraki Partners.

Nos próximos posts vou começar a trazer um pouco mais detalhe técnico dessa solução. Aguardem!!!

Abs,
Rodrigo

Fonte:
https://en.wikipedia.org/wiki/Cisco_Meraki
http://www.cafecomredes.com.br/2017/11/vamos-falar-de-meraki.html

Cisco Meraki – Certificação CMNA – O que é?

Fri, 02 Feb 2018 00:00:00 +0000

Olá Pessoal,

Não sei se todos acompanham o BLOG no Twitter, ou se já haviam visto que eu adquiri a certificação CMNA. O que seria isso?

Bom, a descrição do termo é “ Cisco Meraki Network Associate “. Talvez, vocês estão se perguntando, onde ele fez essa certificação? Qual o valor? Qual treinamento? Quais os conhecimentos necessários?

Enfim, essa certificação não está aberto ao público ( como um CCNA ) e somente é possível executar sendo um parceiro Cisco e obviamente estar associado a esse parceiro, desta forma, você pode se cadastrar nas datas disponíveis para executar um treinamento de 4 horas, após esse período você executa uma prova ( LABzinho ) seguindo algumas instruções disponibilizadas através de um documento. Com a finalização do laboratório o instrutor ( funcionário Cisco Meraki ) faz a validação se todos os itens foram executados e de fato, se está funcionando conforme a solicitação exigida no documento. Os requisitos recomendados no momento de fazer a inscrição é que você tenha conhecimento ao nível de CCNA.

Após esse processo e finalizado você obtém sua certificação. BINGO!!!

Porém, o ponto mais importante e que de fato me chamou atenção na época foi que você finalizando esse treinamento/certificação você ganha 3 equipamentos Meraki com Licença Full por 3 anos. Para quem gosta de um HOMELAB, isso foi perfeito para que eu pudesse ter esses equipamentos e conseguir fazer um upgrade na infra interna. ( rsrsrs. 🙂 ). Somente uma ressalva, esses equipamentos não são entregues no Brasil, ou seja, são disponiblizados apenas nos Estados Unidos.

Os equipamentos disponibilizados são:

Security Appliance – MX-64
Switch – MS220-8P ( PoE / SFP )
Access Point – MR33

Neste caso estou trazendo esse tópico em nosso BLOG, pois em nossos próximos posts vou detalhar um pouco mais sobre esse produto, e claro como estou utilizando esses equipamentos em HomeLAB, vou demonstrar algumas facilidades e problemas, bem como o proposito dessa solução.

Vale lembrar que essa solução apresentada pela Cisco é para determinados segmentos ( minha visão ) e obviamente para abordar esses novos tópicos de SD-WAN.

Abs,
Rodrigo