Quem trabalha com rede e firewall está acostumado a usar o Telnet e o Ping para testes básicos de conectividade. Uma outra opção no Windows, mais recente e completa, é usar o Test-NetConnection (TNC) via Power Shell. Basta informar o hostname ou IP para que o teste seja feito. Por padrão o teste é feito utilizando ICMP, e no output temos o status (True/False), o RTT, o IP de origem e IP de destino (quando usamos hostname o NetConnection já tenta fazer a resolução de nome). Ainda podemos controlar a quantidade saltos (-Hops), fazer o traceroute (-Traceroute) e controlar o nível de informações no output (-InformationLevel Detailed para ver todas as informações). Testando uma porta específica O Test-NetConnection também nos permite testar portas específicas. Neste caso usamos o parâmetro –Port. O status True para TcpTestSucceeded indica que a porta está aberta no host de destino. Test-Connection (Bônus Track) O Power Shell tem outro utilitário, chamado Test-Connection. Ele é mais simples que o Test-NetConnection (que surgiu depois), e serve apenas para teste via ICMP, mas tem uma opção interessante: podemos definir mais de um destino no mesmo comando. Mais informações: Test-NetConnection Test-Connection Até a próxima.
Cisco Cybersecurity Giveaway
Que tal ganhar treinamento e voucher para prova Cisco CyberOps ou Security? Para isso, até 30 de junho de 2022, basta se inscrever neste link. Serão 5 ganhadores, escolhidos aleatoriamente, que poderão escolher entre as opções: Cisco Certified CyberOps Associate Cisco Certified CyberOps Professional CCNP Security O prêmio tem valor aproximado de U$ 1.200,00. Veja aqui todas as informações e condições do sorteio. Até a próxima.
Participação no RotaDefaultVideos
Ontem conversei com o Diego, do sempre recomendado RotaDefault. Falamos sobre blogs, carreira, tecnologia e como as coisas mudaram nestes 14 anos de Brainwork. Deu pra ficar nostálgico… Obrigado Diego, espero repetirmos no futuro.
Cisco Secure Email Domain Assignments (LDAP Profiles)
No post anterior vimos como configurar um LDAP Profile para fazer consultas e verificar se a conta existe, antes de fazer a entrega do e-mail para o servidor. Se você tem mais de um domínio, com servidores separados para cada domínio, podemos criar mais de um profile LDAP, e usar a opção Domain Assignments para apontar cada profile para seu respectivo domínio/servidor. Configuração LDAP Domain Assignments 1) Considerando que já criou os devidos LDAP Profiles, vá em System Administration > LDAP e clique em Add Domain Assignments. 2) De um nome para sua regra, informe o domínio e o respectivo LDAP Profile. Você pode definir (ou não) um dos profiles como Default. 3) Clique em Test, forneça um endereço de e-mail válido e clique Run Test. Faça o teste com um e-mail de cada domínio para validar todos os mapeamentos. Se estiver tudo certo, clique em Done, Submit e Commit. 4) O último passo é associar o Domain Assignment criado ao listener. Vá para Network > Listeners, selecione o listener utilizado para recebimento de e-mails, e na seção LDAP Queries, no campo Accept Query selecione o profile que acabou de criar (neste exemplo Brainwork). Mais informações sobre Domain Assignments no User Guide. Até a próxima.
Consulta LDAPS no Cisco Secure Email (ESA/CES)
O Cisco Secure Email (anteriormente conhecido como Email Security Appliance, ou Cloud Email Security, e muito anteriormente conhecido como Ironport Secure Email), tem uma opção para verificar se o destinatário existe, antes de fazer a entrega para o servidor de e-mail da organização. Para isso é necessário configurar um profile LDAP e associá-lo ao Listener utilizado para recebimento de e-mails. Esta é uma configuração simples, e agrega um bom nível de proteção para o servidor, já que e-mails destinados a contas inexistentes nem são enviadas para ele. Configuração 1) Crie uma conta no AD para Secure Email utilizar para fazer as consultas LDAP. 2) Abra o Secure Email e vá em System Administration > LDAP, e clique em Add LDAP Server Profile. 3) Preencha as informações necessárias: nome do profile, hostname (servidor LDAP), Base DN, usuário e senha (criado no passo 1). Selecione o tipo de servidor, a porta (3268 ou 636 para LDAPS) e marque a opção para usar SSL. 4) Clique em Test Servers. Esse deve ser o output. Connecting to server (IP do seu servidor1) at port 3269 Connected to port: 3269 – Success Bound successfully with DN ces@brainwork.com.br Result: succeeded Connecting to server (IP do seu servidor2) at port 3269 Connected to port: 3269 – Success Bound successfully with DN ces@brainwork.com.br Result: succeeded 5) Selecione Accept Query (o nome e a string devem preencher automaticamente, e a string normalmente é proxyAddresses=smtp:{a}). Clique Test Query e informe um endereço de e-mail válido. O resultado deve ser: Query results for host:(IP do seu servidor1) Query (proxyAddresses=smtp:andre.ortega@brainwork.com.br) to server Brainwork-LDAPS (SERVIDOR1:3269) Query (proxyAddresses=smtp:andre.ortega@brainwork.com.br) lookup success, (SERVIDOR1:3269) returned 1 results Success: Action: Pass Query results for host:(IP do seu servidor2) Query (proxyAddresses=smtp:andre.ortega@brainwork.com.br) to server Brainwork-LDAPS (SERVIDOR2:3269) Query (proxyAddresses=smtp:andre.ortega@brainwork.com.br) lookup success, (SERVIDOR2:3269) returned 1 results Success: Action: Pass 6) Com o profile criado e testes com sucesso, clique em Submit e faça o Commit das alterações. 7) Vá para Network > Listeners, selecione o listener utilizado para recebimento de e-mails, e na opção LDAP Queries, no campo Accept Query selecione o profile que acabou de criar (neste exemplo Brainwork-LDAPS). Clique em Submit, Commit, e pronto. Note que se você usa a solução em nuvem, precisará fazer NAT e liberar no Firewall o acesso do Secure Email para seus servidores LDAP. E importante: a partir de 30 de abril de 2022, a solução em cloud não aceita mais a opção LDAP. É preciso utilizar LDAPS. Se quiser um exemplo desta configuração via linha de comando, acesse este link. E outras informações sobre Query LDAP podem ser encontradas no User Guide. Até a próxima.
Cisco ISE–ACL Redirect nos switches e WLAN Controllers
Access-list pode ser um tópico complicado no mundo de redes. As ACLs comuns, para controle de acesso, normalmente são simples, mas realmente tem casos de uso mais complexos. Um destes casos que pode confundir bastante, é quando usamos access-lists para fazer o redirecionamento em implantações do Cisco ISE. Neste caso precisamos de ACLs nos switches e controladoras para identificar e permitir que tráfego deve ser redirecionado para o portal de autenticação e/ou postura. Access-list “comum”, liberando requisição DHCP, resolução de nome (DNS) e TFTP. Todo o resto é bloqueado. ip access-list extended ACL_PRE_AUTH permit udp any eq bootpc any eq bootps permit udp any any eq domain permit udp any any eq tftp deny ip any any Access-list para Web Redirect. Neste caso NÃO estamos liberando acesso para todo destino com porta 80. ip access-list extended ACL_WEBAUTH_REDIRECT permit tcp any any eq www deny ip any any Este exemplo acima é uma ACL Redirect, e neste caso ela está especificando que o tráfego destinado à porta 80 deve ser redirecionado para a URL recebida do ISE. E a última linha (deny ip any any) permite os demais acessos. É o contrário do que estamos acostumados… Apenas olhando a configuração não é possível ver nenhuma diferença. O que difere é a forma de uso, onde a ACL Redirect é especificada pelo servidor radius (neste caso o ISE), e aplicada à sessão do usuário que está tentando fazer a autenticação. Importante notar que esta ACL de redirecionamento permite todos os demais acessos (o deny na última linha), e normalmente não é isso que queremos antes da autenticação. Então temos que usar uma Downloadable ACL (dACL configurada no ISE) que vai trabalhar junto com a ACL Redirect. Enquanto a ACL Redirect direciona o usuário para o portal de autenticação, a dACL limita o acesso. Exemplo de Downloadable ACL. ip access-list extended ACL_ACESSO_LIMITADO permit udp any any eq 53 permit udp any eq bootpc eq bootps permit tcp any host 10.10.10.55 eq 8443 permit tcp any host 10.10.10.56 eq 8443 deny ip any any A dACL tem o mesmo formato e funcionamento de uma ACL tradicional (permite o que está com permit e nega o que está com deny). A única diferença é que ela está no ISE e é baixada quando necessário. As duas ACL são aplicadas na sessão, e primeiro é verificada a ACL de redirecionamento e depois a dACL. Com as duas access-lists aplicadas temos o seguinte resultado: (ACL R) Tráfico com destino porta 80 é redirecionado para a URL recebida do ISE (Portal Guest). (ACL R) Demais tráfego são permitidos (dACL) Permite consulta DNS (dACL) Permite solicitação DHCP (dACL) Permite acesso ao ISE na porta 8443 (Portal de Visitantes no ISE) (dACL) Bloqueia todo o resto É muito importante entender essa concatenação para que o tráfego válido não seja bloqueado. ACL Redirect na WLC Na WLAN Controller temos os mesmos conceitos, mas a configuração é diferente. No caso da WLC a ACL Redirect funciona ao contrário. Devemos permitir o que deve ser redirecionado e negar o restante. E ao invés da Downloadable ACL temos a Named ACL. A Named ACL é configurada na própria WLC e o ISE envia apenas o nome desta ACL. Postura Ainda falando do ISE, também pode ser necessária uma ACL de redirect quando temos a verificação de Postura. Isso porque o ISE usa um portal no processo de postura (atualmente temos a opção de trabalhar sem isso, mas ainda é uma opção válida), e assim temos a ACL Redirect e dACL/Named ACL para o processo de postura. A diferença do processo de postura e guest é que normalmente permitimos outros destinos, como o servidor de antivirus na dACL. Mais informações sobre ACL Redirect: Central Web Authentication on the WLC Central Web Authentication with a Switch Até a próxima.
