Segurança 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 – Resumo Certificação Cisco CyberOps Associate

Wed, 03 Mar 2021 00:00:00 +0000

Olá Pessoal,

Minha ideia neste post é tentar trazer um pouco da experiência vivenciada para a prova de certificação da Cisco, definida recentemente como Cisco CyberOps Associate.

Provavelmente você deve ter verificado que eu executei minha prova de certificação no final de Dezembro, e desde do final do ano havia colocado esse post como “ rascunho ” e acabei não conseguindo finalizar, porém acho de extrema importância passar um pouco da minha experiência vivenciada nesta prova.

Introdução

Como todos provavelmente devem saber, eu sou instrutor Cisco e leciono os treinamentos dentro das estruturas oferecidas pelo Cisco Netacad, ou seja, os treinamentos que são oferecidos pela Academia Cisco eu posso lecionar, desde que tenhamos os conhecimentos exigidos, e também tenha sido feito o treinamento para instrutores.

Esse treinamento de fato, é feito por um instrutor autorizado Cisco Netacad via ITQ, bem como aluno/instrutor deve executar o curso completo, fazendo todas as provas, e na prova final do treinamento é necessário que tenha uma nota superior a 70% para ser aprovado na academia, e à partir deste momento ele poderia lecionar ou replicar seu conhecimento para os alunos associados em sua academia.

Baseado nesse parâmetro eu já havia visualizado sobre esse conteúdo quando a certificação foi lançada, bem como eu também já havia comentado dela em 2016 nosso BLOG.

Devido a diversos outros fatores, eu não havia conseguido focar nesses tópicos, porém essa área sempre me despertou muito interesse para entender os fluxos, análises, normas, processos e entendimento desse mundo cibernético que vivenciamos a cada dia.

Pois bem, em Junho de 2019 a Cisco anúncio diversas mudanças em seu ciclo de Certificação, e de fato iria começar a valer em Fevereiro de 2020, todas essas alterações vocês podem consultar nos links deixado acima e que eu já havia explorado para vocês.

Para resumir, a certificação CyberOps devido a todas essas nomenclaturas tinhamos informações por trás dos bastidores que poderia ser cancelada nesta cadeia, por ter o contexto que teríamos apenas uma única certificação a nível de Associate, porém a Cisco resolveu deixar essa trilha por se tratar de ítens totalmente apartados, bem como a demanda no mercado estava solicitando esses profissionais para ter um correto entendimento e tratativa para esse mundo denominado cibernético.

Motivação

Baseado em todos os ítens que comentei anteriormente, no terceiro trimestre de 2020, iniciou-se uma campanha forte no Brasil entre Cisco e outras entidades, para que pudessemos trazer mais ênfase os tópicos de Cyber Segurança, e com o intuito final de formar mais estudantes/profissionais nesta área, e que por sua vez esta demandando muitos profissionais capacitados para suportar esses ambientes corporativos e até muitas das vezes residências, como uma forma também educar as pessoas aos seus entendimentos básicos que podemos ter dentro dessa rede mundial denominada “ Internet “.

Após isso, fiquei sabendo que o Netacad Brasil ( via Cisco Brasil ), estava formando instrutores para que esse programa pudesse alavancar, e ter mão de obra disponível para transmitir essa mensagem aos alunos. Devido a isso e também eu estar dentro desse contexto de aprendizagem, eu me inscrevi e fui selecionado para participar da formação de instrutores a nível Brasil.

Enfim, recebemos o cronograma e era extremamente agressivo para acompanhar, pois teríamos em torno de 1 Mês e meio para iniciar e finalizar o treinamento com todas as provas finalizadas. Isso iniciou-se em Setembro e finalizamos na terceira semana de Outubro, onde não tivemos nem feriado para respirar ( rs!! ). Após conclusão do treinamento e por ter ficado entre os 20 primeiros classificados em toda a turma, eu havia ganho um voucher de 100% free, ou seja, não tinha como não dedicar-se para executar a prova de certificação.

Estudos

Desculpa por alongar muito para entrar nos focos deste post, porém resolvi colocar para contextualizar que nossa jornada muito das vezes é longa e árdua, e ela sempre acaba tendo um propósito maior. Enfim, como comentei meus estudos de fato incializaram nos formatos do Netacad ( Learning Networking ), mas antes mesmo de começar o treinamento eu havia visualizado diversos Webinar que a própria plataforma já estava executando para disseminar esse conteúdo.

Com isso recomendo olhar esses vídeos, pois exemplificam o que de fato vocês vão encontrar pela frente:

Após essa dicas eu fiz o treinamento que contém um total de 28 capítulos na plataforma Netacad. Esse conteúdo exige que você tenha conhecimentos na área de redes, pois os conceitos abordados para esse conteúdo de fato estão totalmente relacionados com as estruturas/arquiteturas dos ambientes de Redes.

O que eu visualizo para que você tenha um aproveitamento melhor nos estudos, é que tenha o conhecimento a nível de um CCNA, pois tem muito conceito sobre as camadas do modelo OSI, protocolos de camada 2 ( ARP, Proxy ARP, CSMA/CD, Frame Ethernet, port-security, etc ), cálculo de endereçamento IPv4 e IPv6, NAT/PAT, fora todos os serviços que temos na camada 7 ( SMTP, DNS, HTTP, HTTPs, SNMP, SSH, Telnet, SSL/TLS, FTP, NTP ). Nesta área, muitas análises precisam ser visualizadas através de uma captura de pacotes, portanto é interessante você ter uma vivência com as ferramentas de captura ( Wireshark, tcpdump, nfdump ), pois no treinamento todos esses ítens já são expostos e precisam ter um correto entendimento do fluxo de pacotes em alguns serviços básicos ( TCP, UPD ).

Além de todo esse conteúdo, eu resolvi também ler o livro que foi liberado no final do ano, que está relacionado a certificação que é oferecido pelo Cisco Press. O livro é o CBROPS 200-201 Official Cert Guide escrito pelo Omar Santos. Vale lembrar, que de fato eu não li o livro todo, pois peguei os pontos que estão mais relacionados algumas normas que não eram muito de meu entendimento, mas achei o livro com uma didática boa e de fácil entendimento.

Para os estudantes que desejam seguir com os estudos self-learning, é de extrema importância ler o livro, pois muito do conteúdo exposto precisa ser explorado e de correto entendimento.

Fontes Externas

Obviamente, temos muitos outros conteúdos que acabamos pesquisando para se interar de alguns assuntos que não dominamos, o que no meu caso eram mais os ítens normativos e metodologias sobre relatórios de incidentes, identificação em normas sobre os vetores de ataque, etc.

Em relação a esses ítens recomendo dar uma pesquisada em algumas dessa fontes:

FIRST ( Forum Improving Security Together )
1. CVSS ( Vunerability Score )
2. Calculadora de Vulnerabilidades
NIST
1. Normas sobre Guia de Avaliação de Riscos, Gerenciamento de Patches, etc.
2. Framework Risk Management for Enterprise
MITRE ( ATT&CK ) – Matriz sobre os ataques
MITRE – CVE ( Commom Vunerability )
SGUIL ( Network Security Monitoring )
1. Recomendo instalar e praticar nessa ferramenta.
2. Recomendo obter arquivos de testes neste website ( malware-traffic-analysis ) para praticar suas análises.
3. Execute os exercícios de análise de tráfego para identificação do ataque.

OBS.: É de exterma importância mencionar que essa certificação ela é totalmente vendor agnóstico, e de fato não esta atrelado a nenhum produto da Cisco, ou seja, o foco dela é especificamente treinar e dar o entendimento aos estudantes dos conceitos de Cyber Segurança, treinando ele para trabalhar de fato em um SOC Nível 1.

Resumo

Acredito que eu tenha exposto um pouco da experiência que obtive nos estudos para certificação, espero que isso possa clarificar um pouco a metodologia que você pode seguir para alcançar essa certificação.

Obviamente, talvez em seus estudos você possa encontrar novas fontes ou caminhos para estudar determinados tópicos, e claro sempre observar os tópicos que foram colocados no Blue Print.

O que vocês acharam desse resumo, pode ajudar vocês a encontrar os tópicos e diretrizes para seu estudo? Se tiver dúvidas coloque em nosso comentários para explorarmos os ítens.

Espero que vocês tenham gostado! 🙂

Abs,
Rodrigo

Resumo do BLOG – Referência 2020

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

Olá Pessoal,

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

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

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

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

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

Conquistas

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

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

Certificações

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

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

Conclusão

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

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

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

Abs,
Rodrigo

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

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

Olá Pessoal,

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

Metodologias

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

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

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

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

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

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

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

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

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

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

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

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

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

Proteção

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

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

Residencial

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

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

Corporativo

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

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

Conclusão

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

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

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

Abs,
Rodrigo

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

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

Olá Pessoal,

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

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

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

Autenticação

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

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

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

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

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

Associação

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

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

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

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

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

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

De-Authentication

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

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

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

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

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

Segue nossa tabela abaixo:


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

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

Beacon

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

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

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

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

EAPOL ( Extensible Authentication Protocol Over LAN )

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

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

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

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

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

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

eapol.keydes.type == 2

Conclusão

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

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

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

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

Abs,
Rodrigo

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

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

Olá Pessoal,

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

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

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

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

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

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

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

Instalação

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

Podemos observar a versão instalada:

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

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

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

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

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

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

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

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

Funcionalidades

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

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

Inicialização dos comandos

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

$ sudo airmon-ng check

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

$ sudo airmon-ng check kill

Consolidar iniciando

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

$ sudo airmon-ng start wlan0

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

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

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

$ sudo airodump-ng wlan0mon

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

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

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

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

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

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

E agora?

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

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

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

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

Para efetuar brute force, segue o exemplo:

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

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

Conclusão

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

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

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

Abs,
Rodrigo

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

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 – 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 – Relatório Anual de Cyber Security – 2018

Wed, 21 Feb 2018 00:00:00 +0000

Olá Pessoal,

Hoje a Cisco liberou seu relatório relacionado ao estudo de Cyber Security para 2018. Neste relatório temos bastante informações, porém o que mais me chamou atenção seriam devido a dois ítens, conforme abaixo:\

Como podem observar um dos ítens citados é justamente a não investigação de alertas, que muitas das vezes acabam sendo desconsiderados devido ao não entendimento do problema ou de fato a analise muito equivocada de alguns incidentes. No segundo ponto está co-relacionado sobre esse novo mundo que é sobre orquestração, na qual podemos verificar os grandes desafios a partir do momento que começamos aumentar o número de vendors.

Se deseja analisar segue na integra o Relatório Anual de Cyber Security Cisco 2018.

Att,
Rodrigo

Webinar sobre Cibersegurança

Tue, 28 Mar 2017 00:00:00 +0000

Olá Pessoal,

Gostaria de passar para deixar uma notificação sobre um Webinar que irá acontecer nos dias 5 e 6 de Abril. Esse Webinar será em português e será uma ótima oportunidade para vocês possam aprimorar os seus conhecimentos e aprender com especialistas da Cisco como manter sua informação digital segura.

Para participar, cada um deve se inscrever no curso ” Introduction to Cybersecurity ” acessando o seguinte link e preenchendo o formulário:

Cyber Security Webinar

Após ter feito a inscrição no curso, cada um poderá escolher a sessão Webinar de sua preferência e se registrar.


Informação do Webinar

Webinar Cibersegurança Sessão 1 – Português	5 de abril, 2017	11:00am horário de Brasilia
Webinar Cibersegurança Sessão 2 – Português	6 de abril, 2017	02:00pm horário de Brasília

Passo à passo:

Va para o link https://www.netacad.com/campaign/488224
Inscreva-se no curso de Cibersegurança preenchendo o formulário.
Va até os links das sessões Webinar e escolha a que for de sua preferência.
Se quiser participar nas duas, pode se registrar sem problema nenhum.
Selecione o link “Convite do Webinar” e registre-se diretamente no site da Cisco WebEx.
Você vai receber um email com a confirmação.
No dia do Webinar, entre na sessão pelo menos 5 minutos antes para que possa testar seu audio.
Cada participante receberá um certificado de participação. Para que isso seja possível, é imprescindível que a pessoa tenha se registrado individualmente na sessão Webex que ira assistir. Caso contrario o sistema não terá como gerar o certificado.

Abs,
Rodrigo

BLOG com HTTPS

Sat, 26 Nov 2016 00:00:00 +0000

Olá Pessoal,

Acredito que nem todos tenham percebido alteração que tivemos em nosso BLOG, mas gostaria de notificar, pois acredito que é um dos primeiros a ter um certificado digital operacional garantindo assim a integridade das informações entre o usuario e o servidor de aloção, dando assim confiança maior ao nossos participantes do BLOG.

Veja a informação:

Nos USA isso é uma pratica comum, onde muitas das vezes quando você consulta qualquer BLOG todos utilizam um certificado digital, porém no Brasil não visualizamos muito essa pratica. Porque você acha que não temos muito essa utilização no Brasil?

Deixe seus comentários!!!

Abs,
Rodrigo

Lista de Controle Acesso ( ACL ) – Parte 4

Tue, 16 Oct 2012 00:00:00 +0000

Olá Caros,

Conforme mencionado em nosso último post, vamos tratar de explorar os métodos de configurações de ACL e também explicar com um pouco mais detalhes os conceitos que usamos para ACL.

Neste post irei apresentar a Vídeo Aula que preparei explicando todos os pontos que já estudamos através de nossos post anteriores e adicionado mais um ponto sobre as ACLS ( reflexivas, dinâmicas e temporizadas ). A ideia é preparar e consolidar o conceito de ACL, pois posteriormente vou fazer uma vídeo aula demostrando através de um laboratório as configurações e propriamente o comportamento exercido em um ambiente real.

Segue nossa vídeo aula:

O arquivo .ppt utilizado para a explicação está em nossa seção de arquivos e pode ser feito download para utilizar nos estudos.

Espero que vocês gostem e aproveitem para tirar as dúvidas . Fiquem a vontade para colocar suas dúvidas em nosso post.

Abs,
Rodrigo

Lista de Controle de Acesso (ACL) – parte 3

Wed, 26 Sep 2012 00:00:00 +0000

Olá Caros,

Vamos continuar com nosso tutorial sobre ACL. Conforme em nosso último post iremos tratar sobre a máscara coringa, para qual tem uma pequena alteração na sua formatação.

Para o entendimento dessa máscara coringa, devemos sempre recordar que o assunto de endereçamento IPV4 tem que estar bem fundamentado nos estudos, pois é um fator importante para o entendimento da máscara coringa. Se deseja estudar mais sobre endereçamento IPV4 visite nossos posts.

A máscara coringa é uma string de dígitos binários que informa ao roteador que partes do número da sub-rede deve-se observar. Embora não tenham nenhuma relação funcional com máscaras de sub-rede, as máscaras coringa fornecem uma função semelhante. A máscara determina a proporção de um endereço IP de origem ou de destino a ser aplicada à correspondência de endereço. Os números 1 e 0 na máscara identificam como tratar os bits de endereço IP correspondentes. No entanto, eles são utilizados para fins diferentes, seguindo regras diferentes.

As máscaras coringa e de sub-rede mantêm com seus 32 bits e utilizam 1 e 0 binários. As máscaras de sub-rede utilizam 1s e 0s binários para identificar a rede, a sub-rede e a porção de host de um endereço IP. As máscaras coringa utilizam 1 e 0 binário para filtrar endereços IP individuais ou grupos e permitir ou negar acesso a recursos com base em um endereço IP. Definindo máscaras coringa com cuidado, você pode permitir ou negar um ou vários endereços IPs.

Baseado nessas informações vejamos qual seria o formato dessa máscara coringa:

192.168.2.0 0.0.1.255

Desta forma vocês poderiam perguntar. Qual é a máscara que está sendo utilizada? Como ele chegou nesse valor?

Como de costume essa máscara utilizada acima nos formatos conhecidos vai ser reconhecida como uma /23, portanto teriamos 192.168.2.0/23 ( máscara 255.255.254.0 ). Teríamos disponibilizado para esse range endereços de 192.168.2.0 até 192.168.3.255.

Agora de que forma cheguei naquela máscara coringa, para qual foi através de uma conta matématica muito conhecida por todos, e que acredito que não irá gerar nenhuma dificuldade para praticar. Foi executado a operação de subtração.

Para calcular qualquer máscara coringa devemos executar a subtração da máscara conhecida por 255.255.255.255, ou seja, veja no exemplo abaixo:

255 . 255 . 255 . 255
255 . 255 . 254 . 0 –
=================
0 . 0 . 1 . 255

Com isso podemos tem duas situações que muitas das vezes ficam entendiante devido a trabalhar constantemente com números binários ou números decimais. Devido a isto foi criado duas formas através de palavras chave host e any.

A opção host substitui a máscara 0.0.0.0. Essa máscara informa que todos os bits de endereço IP devem corresponder ou apenas um host é correspondente.

CiscoRedes(config)#access-list permit 192.168.10.10 0.0.0.0
CiscoRedes(config)#access-list permit host 192.168.10.10

A opção any substitui o endereço IP e a máscara 255.255.255.255. Essa máscara diz para ignorar todo o endereço IP ou aceitar qualquer endereço.\

CiscoRedes(config)#access-list permit 0.0.0.0 255.255.255.255
CiscoRedes(config)#access-list permit any

Com isso conseguimos finalizar o misterioso problema que tinhamos com a máscara coringa, desde que tenhamos o conhecimento sobre o cálculo de endereçamento IPV4.

Espero que tenham gostado e no próximo capítulo iremos trabalhar com as ACLs padrão e estendida na forma de linha de configuração.

Abs,
Rodrigo

Lista de Controle de Acesso (ACL) – parte 2

Fri, 14 Sep 2012 00:00:00 +0000

Olá Caros,

Conforme nosso último post, vamos continuar explicando sobre ACLs. Desta forma quando um pacote chega a uma interface do roteador, o processo do roteador é o mesmo, independentemente das ACLs serem utilizadas ou não. À medida que um quadro entra em uma interface, o roteador verifica se o destino do endereço da Camada 2 de destino corresponde ao seu ou se o quadro é de broadcast.

Se o endereço do quadro for aceito, as informações do quadro serão removidas e o roteador verificará se há uma ACL na interface de entrada. Se houver uma ACL, o pacote agora será testado em relação às instruções na lista.

Se o pacote corresponder a uma instrução, ele será aceito ou rejeitado. Se for aceito na interface, o pacote será verificado em relação às entradas da tabela de roteamento para determinar a interface de destino e comutado para essa interface. Em seguida, o roteador verifica se a interface de destino tem uma ACL. Se houver uma ACL, o pacote será testado em relação às instruções na lista. Se corresponder a uma instrução, o pacote será aceito ou rejeitado. Se não houver nenhuma ACL ou o pacote for aceito, o pacote será encapsulado no novo protocolo da Camada 2 e encaminhado pela interface para o próximo dispositivo.

Devemos lembrar que toda ACL criada sempre irá ter um ” deny ” implicito na sua última linha de instrução da ACL, portanto devemos sempre tomar cuidado no momento de aplicar uma ACL em ambientes de produção, pois podemos bloquear todo o tráfego se não lembrarmos do deny implícito.

Nós temos dois tipos de ACLs Cisco:

Padrão = permitir ou negar tráfego de endereços IP de origem. O destino do pacote e as portas envolvidas não importam. O exemplo permite todo o tráfego da rede 192.168.30.0/24. Por conta do ” deny all ” implícito ao final, todo os demais tráfegos são bloqueados com essa ACL. As ACLs padrão são criadas no modo de configuração global.

access-list 10 permit 192.168.30.0 0.0.0.255

Estendida = filtram pacotes IP com base em vários atributos, por exemplo, tipo de protocolo, endereço IP de origem, endereço IP de destino, portas TCP e UDP de origem, portas TCP e UDP de destino e informações do tipo de protocolo opcionais para maior granularidade de controle. No exemplo a ACL 103 permite tráfego com origem em qualquer endereço na rede 192.168.30.0/24 para qualquer host de destino na porta 80 (HTTP). As ACLs estendidas são criadas no modo de configuração global.

access-list 103 permit tcp 102.168.30.0 0.0.0.255 any eq 80

Dentro dessa caracteristíca podemos ter as ACLs nomeadas e ACLs numeradas. Segue as características:

Numerada = Você atribui um número com base no protocolo que você deseja filtrar:

(1 a 99) e (1300 a 1999): ACL IP padrão

(100 a 199) e (2000 a 2699): ACL IP estendida

Nomeada = Você atribui um nome, fornecendo o nome da ACL

Os nomes podem conter caracteres alfanuméricos.

Sugere-se que o nome seja escrito em LETRAS MAIÚSCULAS.

Os nomes não podem conter espaços ou pontuação, devendo começar por uma letra.

Você pode adicionar ou excluir entradas dentro da ACL.

Neste contexto podemos nos perguntar, onde devo colocar o ACL e qual tipo devo utilizar?

Toda ACL deve ser colocada onde tenha o maior impacto em termos de eficiência, ou seja, as regras básicas que devemos assumir é:

Coloque as ACLs estendidas mais próximas da origem do tráfego negado. Dessa forma, o tráfego indesejável é filtrado sem atravessar a infraestrutura de rede.
Como as ACLs padrão não especificam endereços de destino, coloque-as o mais próximo possível do destino.

Na foto acima posso aplicar uma ACL estendida no router A para evitar que o tráfego de entrada no roteador seja trafego por toda a extensão da rede até sua chegada no destino, ou seja, evitando utilização de banda sabendo que esse tráfego vai ser bloqueado para alcançar seu destino. E podemos aplicar uma ACL padrão no router C, pois somente temos os endereços de origem para serem bloqueados.

Espero que tenham gostado e no próximo capítulo vou explicar um pouco sobre a máscara coringa que utilizamos nas ACLs .

Abs,
Rodrigo

Lista de Controle de Acesso (ACL) – parte 1

Sat, 25 Aug 2012 00:00:00 +0000

Olá Pessoal,

Conforme prometido em nosso post de ACL, vamos iniciar nosso tutorial explicando um pouco sobre ACL. Uma das habilidades mais importantes das quais um administrador de rede precisa é dominar as listas de controle de acesso (ACLs). Os administradores utilizam as ACLs a fim de parar o tráfego ou permitir apenas o tráfego especificado enquanto interrompe todo o restante do tráfego em suas redes.

Uma ACL é uma lista sequencial de instruções de permissão ou negação que se aplicam a endereços ou protocolos de camada superior. As ACLs fornecem uma forma eficiente de controlar o tráfego dentro e fora da sua rede. Você pode configurar as ACLs para todos os protocolos de rede roteados. A razão mais importante para configurar as ACLs é fornecer segurança para a sua rede e utiliza-las para outro paramentros ( QoS, validação de tráfego, etc ).

Os pacotes TCP são marcados com flags que denotam sua finalidade: SYN inicia (sincroniza) a sessão; ACK é uma confirmação (ACK) de que o pacote aguardado foi recebido e FIN encerra a sessão. SYN/ACK confirma que a transferência foi sincronizada. Devido as validações que devemos executar referenciando-se muitas vezes as portas, segue uma tabela com os intervalos:


Intervalo de Número de Portas	Grupo de Portas
de 0 a 1023	Portas conhecidas ( comum )
de 1024 a 49151	Portas registradas
de 49152 a 65535	Portas dinâmicas e/ou privadas

Uma regra geral para aplicar as ACLs em um roteador pode ser lembrada, basta memorizar os três Ps. Você pode configurar uma ACL por protocolo, por direção, por interface:

ACL por protocolo = para controlar o fluxo de tráfego em uma interface, uma ACL deve ser definida para cada protocolo habilitado na interface.
ACL por direção = ACLs controlam o tráfego em uma direção por vez em uma interface. Duas ACLs separadas devem ser criadas para controlar os tráfegos de entrada e de saída.
ACL por interface = ACLs controlam o tráfego de uma interface, por exemplo, Fast Ethernet 0/0.

Lembre-se de que uma ACL é uma lista sequencial de instruções de permissão ou negação que se aplicam a endereços IP ou protocolos de camada superior. A ACL pode extrair as seguintes informações do cabeçalho do pacote, testá-lo em relação às suas regras e tomar decisões ” permitir ” ou “ negar ” com base em:

Endereço IP de origem
Endereço IP de destino
Tipo de mensagem ICMP

A ACL também pode extrair informações de camada superior e testá-las em relação às suas regras. Entre as informações da camada superior estão:

Porta de origem TCP/UDP
Porta de destino TCP/UDP

Portanto nesse caso devemos reforçar que os pacotes são analisados a partir da camada 3 ( Redes ) do modelo OSI e por consequência as camadas superiores podem ser avaliadas, como camada 4 ( TCP e UDP ). Na medida em que cada pacote passa por uma interface com uma ACL associada, a ACL é verificada de cima para baixo, uma linha por vez, procurando um padrão correspondente ao pacote de entrada, se a condição foi atendida dentro daquela ACL especificada nenhuma linha inferior será executada, ou seja, todo o restante daquela ACL não será validada.

Como toda validação é feita a partir da camada 3, ou seja, a carga de trabalho dependendo da sua topologia será direcionada para o roteador ( gateway ), na qual teremos as ACLs aplicadas como IN ou OUT. Devemos sempre lembrar que ambas exercem funcionalidades distintas na análise do roteador:

ACLs de entrada = Pacotes de entrada são processados antes de serem roteados para a interface de saída. Uma ACL de entrada será eficiente porque evita a sobrecarga das pesquisas de roteamento se o pacote for descartado. Se for permitido pelos testes, o pacote será processado para roteamento.
ACLs de saída = Pacotes de entrada são roteados para a interface de saída e, em seguida, processados pela ACL de saída.

Espero que tenham gostado dessa primeira introdução e aguardem cenas do próximo capítulo.

Abs,
Rodrigo