O programa Cisco Champion, que participamos já tem alguns anos, está com inscrições abertas para 2022. Para quem ainda não conhece o programa visa incentivar a comunidade de influenciadores técnicos. Como Cisco Champion, você: Tem informações antecipadas sobre novos produtos e soluções Cisco Tem acesso aos principais engenheiros da Cisco Aumenta sua rede de contatos entusiastas de tecnologia (no último ano haviam participantes de mais de 60 países) Fornece feedback sobre produtos e soluções, por meio beta testing, message testing, focus groups, e Webex Teams spaces E ainda tem lugares especiais, passeios pelos bastidores e outros no Cisco Live, quando voltar a ser presencial Se você gosta de compartilhar informações técnicas (através de blog ou página em qualquer comunidade), acesse o formulário e faça a inscrição. Em caso de dúvida, pergunte no Twitter @CiscoChampion ou post com a #CiscoChampion. Até a próxima.
Ferramenta para migração de switches Cat2K para Meraki MS
O site https://check.netdecorators.com/ fornece duas opções para quem está se preparando para migrar switches Cisco Catalyst 2K para switches Meraki MS. Criado por Fady Sharobeem, Solution Architect da Meraki, podemos (1) fazer o upload de um arquivo de configuração e ver quais funcionalidades em uso são ou não suportadas no Meraki. E (2), automatizar a migração da configuração, do arquivo diretamente para a dashboard Meraki. No caso da migração, além do arquivo com a configuração existente é necessário fornecer a chave API da sua dashboard. Bacana né? Até a próxima.
Descomplicando o Log4Shell
O Flávio Costa, Technical Solutions Architect for Channels in LATAM at #CiscoSecure, escreveu um ótimo artigo sobre o Log4Shell no Linkedin, e com a devida autorização estou compartilhando abaixo. ${jndi Na quinta-feira, dia 9 de dezembro, foi anunciada uma vulnerabilidade dia zero de validação de input, (CWE-20 improper input validation), que ocorre quando dados não confiáveis são usados para manipular como eles são tratados pelo sistema, que pode resultar em uma execução de código remoto, (T1203 – Exploitation for Client Execution), ou seja, um usuário mau intencionado, sem qualquer privilégio ou autenticação, poderia com um único comando (T1059 – Command and Scripting Interpreters) exfiltrar informações sensíveis (TA0010), e executar um código malicioso remotamente. Honeypots já observaram ataques de criptomining adaptando essa vulnerabilidade. Trata-se de uma biblioteca de registros (logging), open-source desenvolvida pela Apache, bastante popular chamada Log4j. A vulnerabilidade foi descoberta pelo especialista de segurança em nuvem, Chen Zhaojun, da Alibaba (CVE-2021-44228, CVSSv3 10.0). Além disso, Kenna, o software de gerenciamento de vulnerabilidade baseado em risco da Cisco, está rastreando essa vulnerabilidade e atribuiu a ela uma pontuação de risco de 93 de 100, uma pontuação excepcionalmente rara que reflete a gravidade e o impacto potencial dessa vulnerabilidade. Para colocar isso em perspectiva, o Log4j é mais arriscado do que 99,61% das mais de 165.000 vulnerabilidades que o Kenna já pontuou. “A project with a footprint like Log4j is not possible to avoid as a transient dependency even if you don’t directly import it. Log4j is a canonical logging utility for a huge ecosystem. Its current radius is beyond doing due diligence.” – @rakyll (AWS) Basicamente, se estamos falando de algo que tem esse framework Java de subsistema de registro, na versão 2.x, então ele está potencialmente vulnerável, ou seja, a superfície de ataque é enorme, pois é amplamente utilizado por muitas aplicações e serviços em nuvem, podendo se tornar uma das vulnerabilidades mais sérias na internet desde Heartbleed e ShellShock. Por isso, um dos nicknames utilizados como referência à vulnerabilidade pela LunaSec, Log4Shell, faz bastante sentido. O nome representa fielmente o impacto (TA0040), e a facilidade de acesso inicial (TA0001). Já foram observados scans ativos (T1595 – Active Scanning) na internet procurando por alvos, e diversas formas diferentes de exploração. Um dos primeiros alvos identificados foi através do chat do jogo Minecraft. Fonte: Canal do YouTube do John Hammond Steam, Apple iCloud e vários outros serviços em nuvem também foram encontrados vulneráveis. Relatórios da Cisco indicam tentativas de exploits desde o dia 1 de dezembro. Esta vulnerabilidade representa um risco significativo para os sistemas afetados e tem grande probabilidade de ser explorada a partir dos próximos dias, podendo impactar milhares de organizações. Mas para entender como funciona uma biblioteca Java, precisamos entender alguns conceitos, que vou explicar de uma forma simples para contextualizar o cenário: Dados fornecidos por um usuário não confiável, que você está meramente imprimindo para referência futura ou registrando em um arquivo, podem assumir o controle do servidor no qual você está fazendo o registro. Para entender como isso pode ser feito, vamos utilizar como exemplo o pequeno código abaixo, “teste1print.java”: Após compilar e rodar o código, teremos como resposta a impressão da string: Simples né? Basicamente temos o print do famoso “Hello World!” Observe que antes da execução do programa em Java, foi executada uma definição de classe, pelo comando set CLASSPATH, para utilização de módulos da versão vulnerável 2.14.1. Com algumas pequenas modificações no código para adicionar a função error() utilizada como registro e no nível padrão, (assim não precisamos criar um arquivo de configuração Log4j), estamos usando o primeiro argumento da linha de comando como o texto a registrar, então podemos injetar o texto externamente, como fizemos acima. Arquivo modificado para “teste2log.java”: O resultado agora da execução deste novo código é: E pronto, temos uma aplicação utilizando a versão vulnerável do Log4j. Como podemos explorar essa falha? Lookups do Log4j2 (versão 2.x) fornecem uma forma de adicionar valores à configuração do Log4j em locais arbitrários. Simplificando, o usuário que está fornecendo os dados que você está planejando registrar pode escolher não apenas como eles são formatados, mas até mesmo o que eles contêm e como esse conteúdo é recebido. Invariavelmente, além de comprometer a integridade dos registros, pode também revelar dados de outro lugar em seu servidor que você não teria interesse em publicar. Esses lookups¸ ou pesquisas, no Log4j são acionados por sequências ${….} especiais, como estas: Repare que as variáveis, por exemplo ${java:version}, foram substituídas por valores, neste exemplo, “Java version 17.0.1“, sem qualquer tratamento/validação desse input. Já entendeu onde podemos chegar? Como exemplo, a maioria dos clientes web inclui um header (cabeçalho) HTTP chamado User-Agent, e a maioria dos servidores HTTP mantém um registro dessas informações para renderizar a página corretamente e ajudar os administradores a decidir sobre suporte a outros navegadores de acordo com a demanda. Modificar essa informação por valores específicos pode causar sérios problemas, salvando dados em disco que eram para ser armazenados somente em memória. O problema reside especificamente no lookup para Java Naming and Directory Interface (JNDI), uma API que permite o lookup de objetos através de vários protocolos, entre os mais populares para esta vulnerabilidade: LDAP/S, RMI e DNS. O Log4j analisará a entrada e procurará qualquer uma das pesquisas, tratando todos os argumentos como format strings, processando automaticamente o lookup assim que encontrado. Essas sequências de comandos podem não apenas fazer simples substituições de strings como demonstrado acima, mas também fazer pesquisas em tempo de execução para servidores arbitrários, tanto dentro quanto fora da rede. Como exemplo, podemos utilizar o ncat, um programa que irá escutar conexões TCP e relatar quando obtiver uma, para que possamos ver se o Log4j realmente está fazendo conexões de rede: Para explicar as opções de linha de comando do ncat: -k continuar ouvindo as conexões, não sair após a primeira ser estabelecida; -vv verbose, para que possamos verificar nos logs ele está em listening; -c especifica um comando que envia uma resposta para
Componentes AVI Networks Load Balancer (NSX Advanced Load Balancer)
A AVI Networks, empresa americana, foi fundada em 2012, e tem no balanceamento de carga sua principal solução. Em 2019 foi adquirida pela VMware e tem se popularizado (sendo que o produto agora é chamado de NSX Advanced Load Balancer). O principal diferencial da solução AVI é trabalhar nativamente no conceito SDN – Software Defined Network, diferente dos fabricantes tradicionais de balanceadores. Toda a solução AVI é baseada em software, podendo trabalhar on-premises ou em clouds (privadas e públicas). Também é importante notar que a mesma Controller pode gerenciar Services Engines distribuídos em múltiplas clouds. Componentes da solução A solução conta com plano de controle e com plano de dados separados, conforme conceito SDN. AVI Controller: Responsável pelo plano de controle, faz a função de Controller e também de Management. É o cérebro da solução, sendo implementada como appliance virtual standalone (1) ou redundante (3 neste caso). Utiliza API para comunicação e visibilidade das aplicações. Quando no modo “write” é capaz de provisionar automaticamente novos Services Engines. Prove a console para configuração e monitoramento da solução, com Insights e APIs para integração com outras soluções. AVI Service Engine: São appliances virtuais, responsáveis pelo plano de dados. Nestes appliances criamos os “Virtual Services”, que são de fato os balanceadores. Um Service Engine pode ter um ou mais Virtual Service. Além do papel de Load Balancing, podemos ter Global Load Balancing e Web Application Firewall. Podemos ter redundância de SE (Ativo/Backup ou Ativo-Ativo, com Virtual Services distribuídos nos SEs). Virtual Service: Aplicação criada no Service Engine responsável pelo balanceamento de carga. As configurações que o “cliente vê” (VIP por exemplo) estão no Virtual Service. Cloud, SE Group e Folder: Cloud é o local onde o Service Engine vai ser instalado (não precisa ser literalmente uma cloud). SE Group, como o nome sugere, nos permite criar grupos de Service Engines, dentro de uma mesma Cloud, e define um domínio de falha. Escalonamento, failover e dados de sessão são sincronizados dentro do mesmo grupo. E Folder é um agrupamento dentro do SE Group, para organização. Pool: Onde criamos a lista de servidores/aplicações que serão balanceadas. Redundância de Controllers Quando trabalhamos com 3 Controllers todas ficam ativas (uma como Leader e as demais Followers), e elas compartilham a carga (Virtual Services são distribuídos entre as Controllers). A gerência da solução pode ser feita a partir de qualquer Controller e não apenas na Leader. E como solução SDN, a queda de uma Controller não afeta o processamento do tráfego, que é feito pelos Service Engines. Se duas Controllers ficarem indisponíveis a controladora restante precisa ser manualmente promovida a “líder”, não impactando no balanceamento de carga. E mesmo se as 3 controladoras ficarem indisponíveis, o tráfego não é impactado nos balanceadores. No entanto, neste momento, não seria possível fazer alterações na configuração. Data Plane Scaling Uma característica bastante interessante da solução é a facilidade de crescimento. Podemos criar novos Virtual Services em um mesmo Service Engine, e se necessário adicionar mais CPU e memória no SE (necessário reiniciar), ou então criar novos Service Engines (pode ser feito automaticamente pela Controller), e distribuir a carga usando BGP ou modo nativo. No modo nativo a Controller cria um novo Service Engine, e o SE existente (primário) recebe todo o tráfego e redireciona parte para o novo SE. Mais detalhes sobre a solução nos links abaixo: AVI Networks Architectural Overview AVI Networks NSX Advanced Load Balancer AVI Netowkrs Doc Até a próxima.
Tipos de updates no Cisco Secure Firewall (FMC/FTD)
É sempre muito importante manter o firewall (e demais equipamentos) atualizados. E no caso do Cisco Secure Firewall (anteriormente chamado NGFW, e na pratica conhecido como Firepower), temos alguns tipos de updates, específicos para diferentes componentes. Note que não basta atualizar o software do equipamento para ter as assinaturas de IPS mais recentes, por exemplo. Fora o update de software, os demais componentes podem fazer atualizações automáticas, de acordo com o agendamento configurado. Software Upgrade/Update Nesta categoria temos 4 tipos, sendo as duas primeiras mais comuns/recorrentes. Major: Updates que contém novas funcionalidades e melhorias. Da 6.6.4 para a 6.6.5, por exemplo. Maintenance: Contém correções de bugs e relacionadas à segurança (6.6.4.1, por exemplo). Engloba correções lançadas anteriormente nos patches e hotfixes. Patches: Updates “on-demand”, limitados a falhas críticas (Ex. 6.5.0.1). Hotfixes: Pacotes também específicos, para correções pontuais (Ex. 6.5.0.1). Os arquivos de update tem nomes como “Cisco_Firepower_Mgmt_Center_Upgrade-6.6.5-81.sh.REL.tar” e “Cisco_Firepower_Mgmt_Center_Patch-6.4.0.12-112.sh.REL.tar”. Vulnerability Database (VDB) Atualização da base de dados de vulnerabilidades que podem atingir os hosts. Inclui fingerprints para detecção dos sistemas operacionais, clientes e aplicações. Exemplo de nome do arquivo: Sourcefire_VDB_Fingerprint_Database-4.5.0-241.sh GeoLocation Database (GeoDB) Updates sobre a localização geográfica dos Ips públicos (Ex. Cisco_Firepower_GEODB_Update-2021-10-04-002.sh.REL.tar). Intrusion Rules (SRU) Atualização que contém as assinaturas IPS e pré-processadores. Também tem os estados das regras e categorias. Para baixar manualmente busque o arquivo com nome “Cisco_Firepower_SRU-2021-10-06-001-vrt.sh.REL.tar”. Security Intelligence Feed Responsável por atualizar a lista de IPs e domínios e suas respectivas categorias/reputações. Download feito pelo FMC, direto da cloud (precisa de acesso à Internet) URL Filtering Data Atualização da lista de URLs, categorias e reputação, usadas nas Access Control Rules. Download feito pelo FMC, direto da cloud (precisa de acesso à Internet) Na tabela abaixo temos outros detalhes sobre cada tipo de atualização, e também o caminho no FMC onde podemos fazer o update. Mais informações sobre atualizações no Cisco Secure Firewall podem ser encontradas neste link. Até a próxima.
Upgrade FTD no FMC 7.0.0
Com a versão 7.0.0 do FMC – Firewall Management Center, ficou mais fácil o processo de upgrade do FTD – Firepower Threat Defense. Agora o FMC conta com um guia para upgrade do FTD, onde com poucos passos a atualização é realizada. Basicamente selecionamos o device, a nova versão e então enviamos o software para o equipamento. Atualizando o FTD no FMC 7.0.0 1) Acesse Devices > Device Upgrade e clique em Device Management. 2) Selecione os firewalls que deseja atualizar (recomendado não fazer mais do que 5 por vez). Clique em Select Action e escolha a opção Upgrade Firepower Software. 3) De volta a página de upgrade, selecione a versão de software que será usada (ela precisa já ter sido enviada para o FMC). E então selecione a opção Copy Upgrade Package. 4) Após a cópia clique em Next. 5) Selecione a opção Run Redadness Check, para validar o software e a compatibilidade com o device. 6) Após a verificação ser concluída (verá o status Passed abaixo da opção Compatibility and Readiness Check), clique em Next. 7) Na tela seguinte basta selecionar Start Upgrade para iniciar a atualização. 8) É possível acompanhar o processo na tela de upgrade, ou no menu de tarefas. 9) Pronto, firewall atualizado com sucesso. Esse processo nos permite enviar o software e fazer a verificação antes do upgrade, sem parada no ambiente. Somente após selecionar Start Upgrade (passo 7) é que a atualização é de fato iniciada e o firewall reiniciado. Neste exemplo o upgrade demorou cercada de 20 minutos, mas esse tempo pode variar de acordo com o modelo do firewall. O FMC 7.0.0 não gerencia FTD com versões anteriores a versão 6.4.0. Com relação os firewalls, apenas os appliances Firepower, ASA5508X e 5516X, e ISA3000 podem ser atualizados para o FTD 7.0.0. Para todos os detalhes do processo de atualização veja o Upgrade Guide e a matriz de compatibilidade. Até a próxima.
