(Vamos lá!) De ontem (dia 16) até o próximo dia 27 de outubro estarei participando do Pergunte ao Especialista, na Comunidade de Suporte Cisco. O tema desta vez é o Firepower Management Center, software para a administração dos NGFW e NGIPS Cisco. Abaixo mais informações. O Firepower Management Center (FMC), é o software para gerência centralizada e completa dos NGFW e NGIPS Cisco.Com ele podemos administrar eventos de segurança e políticas, com total visibilidade de usuários, protocolos, hosts e arquivos. Participe do Pergunte ao Especialista e entenda como o Firepower Management Center pode ajudar na proteção contra ameaças avançadas, integrar com outras soluções como AMP for Endpoint e ISE e ainda simplificar a administração do NGFW e NGIPS Firepower. Faça suas perguntas de segunda-feira, 16 de Outubro a sexta-feira-feira 27 de Outubro de 2017 Especialista em Destaque André Ortega Trabalha há 12 anos com redes Cisco, atuando atualmente no time de engenharia da Added, dando suporte aos times de pré e pós venda. Tem trabalhado com soluções de segurança e Wifi, além de manter o blog brainwork.com.br.André é formado em Ciência da Computação e Processamento de Dados, com certificações Cisco (CCNP Routing & Switching) Basta postar as dúvidas na comunidade que estarei respondendo. Até a próxima.
Configurando VPN Remote Access no FTD
(Só seguir o wizard) Como podemos ver, basta seguir o wizard para configurar uma VPN Remote Access. O único detalhe é instalar o certificado (caso ainda não esteja instalado) antes de fazer o deploy da configuração. Documentos úteis: Firepower Threat Defense Remote Access VPNs Firepower Threat Defense VPN Troubleshooting Até a próxima.
VPN Remote Access no Cisco FTD
(Finalmente) Enfim temos VPN Remote Access no Cisco FTD. A funcionalidade foi lançada na versão 6.2.1, apenas para os appliances Firepower 2100. E agora, a partir da versão 6.2.2 (lançada em setembro), a funcionalidade está disponível para todos os appliances. Ainda não temos todas as opções que tínhamos anteriormente no Cisco ASA (que convenhamos era uma solução bastante completa), mas as principais funcionalidades estão disponíveis. Gerenciamento: Feito através do FMC ou FDM, possui um wizard para configuração, onde configuramos profiles, políticas, pool de endereços, adicionamos a imagem do Anyconnect, e selecionamos a interface onde a VPN será habilitada. Acesso Seguro: Fornecido pelo cliente Cisco AnyConnect (computadores, dispositivos Android e IOS) usando protocolos de encapsulamento e codificação SSL ou IPsec. AAA: Suporte à autenticação (LDA / AD / RADIUS, usando usuário e senha e/ou certificado), autorização (atributos RADIUS – DACL, política de grupos, atribuição de IP, etc), contabilidade (accounting) RADIUS. Conectividade: Os perfis de conexão e as políticas de grupo permite definirmos o servidor DNS, o horário permitido para acesso, ACLs de firewall para o cliente. Solução de Problemas: Tela para troubleshooting, com logs úteis para solução de problemas na criação ou uso da VPN RA. Disponibilidade: O firewall pode estar em HA, ter múltiplas interfaces (dois ISPs) e vários servidores AAA. Licenciamento: Smart Licensing, baseado na versão AnyConnect 4.x, para licenças Apex, Plus e VPN-Only. Mais informações sobre VPN RA no FTD e outras novas funcionalidades disponíveis na versão 6.2.2 no release notes. Até a próxima.
Trojan brasileiro mira Internet Bankings
(Temos ótimos desenvolvedores, não há dúvida) Trojans com foco nos internet bankings não são novidade, e o Talos, grupo da Cisco focado em segurança e análise de ameaças avançadas, descobriu uma nova campanha, muito provavelmente criada por brasileiros, focada no acesso ao nossos bancos online. Esta campanha foi direcionada à vários bancos sul-americanos na tentativa de roubar as credenciais dos usuários para permitir lucros financeiros ilícitos para os atores mal-intencionados. A campanha analisada pelo Talos é focada em usuários brasileiros, e também tenta permanecer sigilosa usando vários métodos de re-direção na tentativa de infectar a máquina da vítima. O trojan ainda usa múltiplas técnicas de análise e o payload final foi escrito em Delphi, o que é bastante incomum nestes casos. Como é normal atualmente, o maior meio de infecção é através de e-mails falsos (SPAM), que neste caso é escrito em Português, e contém um anexo chamado BOLETO_2248_.html. Este anexo possui uma URL, que redireciona para outra URL, e então para outra, e outra, até que um arquivo .RAR é baixado. Descompactando e executando o .JAR (dois cliques) é iniciada a execução do código malicioso. Esse código baixa outros arquivos. O primeiro inclusive, é um arquivo não malicioso e assinado pela VMware, na sequencia outros componentes são baixados. Esta técnica permite escapar de alguns produtos de segurança que analisam apenas o primeiro arquivo (se esse for considerado seguro, os demais itens não são verificados). Após instalado o foco do trojan, que possui uma série de funcionalidades, é monitorar se o usuário está acessando algum Internet Banking (entre eles estão Sicoobnet, Itaú, Banestes, Banrisul, Bando do Brasil, Caixa, Sicredi, Bradesco). E então o trojan é capaz interagir com a página e roubar os dados do usuário. Acredita-se que o desenvolvimento seja brasileiro porque há strings em português no código, além do trojan comunicar-se com servidores hospedados no Brasil (Locaweb). A descrição completa da análise do Trojan e outras informações podem ser encontradas no blog do Talos. Até a próxima.
Adicionando um rota no vCenter Server Appliance (VCSA) 6.5
(Já que o mundo não acabou no fds…) O VMware VCSA – vCenter Server Appliance, é um virtual appliance rodando Linux customizado, onde temos o vCenter e demais serviços associados. Para adicionar um rota neste appliance, precisamos logar via linha de comando e então acessar o shell. Command> shell Shell access is granted to root root@labvcenter [ ~ ]# Vá para o diretório network, e verifique o arquivo de configuração existente. Normalmente terá apenas um arquivo, chamado 10-eth0.network. É este arquivo que devemos editar para adicionar a rota desejada. root@labvcenter [ ~ ]# cd /etc/systemd/network/ root@labvcenter [ /etc/systemd/network ]# ls 10-eth0.network root@labvcenter [ /etc/systemd/network ]# Abra o arquivo com o VI e insira uma nova seção com os seguintes parâmetros (especifique a rede desejada e o respectivo gateway): [Route] Gateway=10.123.45.254Destination=10.10.8.0/22 Salve a alteração e verifique usando o comando more. Para a configuração ter efeito, reinicie o serviço de rede. systemctl restart systemd-networkd Prontinho. Podemos usar o comando ip route show para confirmar que a configuração teve efeito. Até a próxima.
Gerando CSR e importando certificado na Cisco WLC
Importar certificado para a WLC Cisco era um processo chato, que requeria a geração do CSR externamente. Felizmente, a partir da versão 8.3.102 as coisas ficaram um pouco melhores. Agora podemos fazer a solicitação do certificado diretamente na CLI da controladora. Neste exemplo vamos ver como requisitar e instalar o certificado na WLC, que o utilizará no portal para autenticação de visitantes (portal padrão, interno). O ideal é utilizar um servidor externo com o portal de autenticação (Cisco ISE), mas em alguns casos o portal padrão pode ser útil. 1) O primeiro passo é gerar o CSR (requisição de certificado). Acesse a WLC via linha de comando e digite: config certificate generate csr-webauth BR SP SaoPaulo Brainwork TI guest.brainwork.com.br admin@brainwork.com.br —–BEGIN CERTIFICATE REQUEST—– MIIC0jCCAboCAQAwgYwxCzAJBgNVBAYTAkJSMQswCQYDVQQIDAJTUDERMA8GA1UE BwwIU2FvUGF1bG8xDjAMBgNVBAoMBUFkZGVkMQswCQYDVQQLDAJUSTEbMBkGA1UE AwwSZ3Vlc3QuYWRkZWQu39dtLmJyMSMwIQYJKoZIhvcNAQkBFhRzZWN0ZWFtQGFk ZGVkLmNvbS5icjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOURtLKi ZGTL+42UrmLmp4arJBGActvklLw+9vJ8tqNzfR5rl7RhJ5kiHcV+t/bCWSRWmBVo BN6uquJFtxOGVKnCB+o9LRUhVOyuzQ6PeWZFl6uzLDSKWilsGSgP2upeeMGRH7F8 +MXbwjgsXxq3/f7FFHMPybrqSHBFzKCj53u3r0PxUTKG6iMhG7nuUfcYdwBdmoFe csjSfkb+YQeZmELDo2rogfFnG9a/jlp+fuJNJasdfasdffsadf3xzCCDlNve6F47+Fkk FzDG4p8ffyQZuKkMhP/HO5NePEqRT0zAvzsT+BD7Bj+Sfl7F1/ghF7enRs5yD5TU swsT1fLYf33cmXECAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQBe7qbz3Hz340kM yTUdVjIM1VxTSXzr7TqtIqQBVy6ZdA9wOpX4sdfdffEEaXVNRHMvE4E/th3rA8whsNS L/TD0rndFBFqjj9Eg3kshQQ9wVKoECXhmevpMbXy5jTY2I1AVyerP92Jam25xZiw GOLCjku1ETNpWo17svOHBRXCeDkSMFQDBhdo5t1XFZqmtlhki7THHmqVD3I0a/M2 uHpZYDWhZLmqlVz9pjIS3QRXrk1UJ+Lqn+5b1FuS0I6WZfSCd8ZZolhy8FvDgNq4 rISbBmK5+YjkXPj7jtvKcxQ5PdSN6uQhyUYzOL6Wy7WSsHVABl+Prd3EKXeLTt/F 8GnZTZ8K —–END CERTIFICATE REQUEST—– Copie o output completo e cole no bloco de notas. Note que estamos solicitando um certificado para usar no portal de autenticação para visitantes. Se quiser usar o certificado para acesso administrativo o comando é config certificate generate csr-webadmin. 2) Envie o CSR (output que colou no bloco de notas) para a entidade certificadora para a geração do certificado para a WLC. Neste exemplo usarei a CA Microsoft, mas em um ambiente real devemos usar uma entidade pública, pois os visitantes não vão conhecer (muito provavelmente) sua CA privada. 3) Além de fazer o download do certificado da WLC, também precisamos baixar o certificado da própria CA. No caso de uma CA pública, enviamos o CSR e eles devolvem o certificado da WLC e o Certificado Root, bem como possíveis intermediários. 4) Neste momento temos dois arquivos “.cer” (o Certificado da WLC e o Certificado da CA). Abra ambos com o bloco de notas, e copie o conteúdo dos dois em um único arquivo. IMPORTANTE que esteja na ordem: primeiro o Certificado da WLC e Depois do certificado da CA. Se tiver alguma entidade intermediária a ordem é: Certificado do Device (WLC), Certificado Intermediário, Certificado Root. Salve o arquivo com um nome qualquer “.pem” (All-certs.pem, neste exemplo). 5) Transfira o arquivo para a WLC. Na interface web vá em Security > Web Auth > Certificate. Selecione a opção Download SSL Certificate e informe os dados. Clique em Apply. 6) Na sequencia, salve a configuração e reinicie a WLC. 7) Prontinho. Pode ir em Security > Web Auth > Certificate e confirmar que o novo certificado está disponível. A parti daqui basta criar uma WLAN com Webauth para o novo certificado ser utilizado. Alguns pontos importantes: O CSR gerado pela WLC não permite a utilização do campo SAN, e por isso alguns browser podem continuar alarmando antes de abrir seu portal de autenticação. Alternativamente, podemos usar o OpenSSL parar gerar o CSR, inclusive com o campo SAN. A partir da versão 7.6 apenas chained certificates são suportados. O CN precisa dar match na URL que será utilizada (criada na interface virtual, e cadastrada no DNS Server). Se após a geração do CSR, antes de importar o certificado para a WLC, a WLC for reiniciada, ela ficará inacessível via HTTPS. Mais detalhes aqui. Até a próxima.
