Umbrella on Cisco Redes

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

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. 😛