Arquivo

Arquivo do Autor

O melhor firewall e anti-malware do mundo – você mesmo – Parte 1

2 de novembro de 2017 Deixe um comentário

Saudações,

A algum tempo não venho escrevendo neste espaço por pura falta de tempo. Mas algumas inicitivas que tenho divulgado na minha fan page estão ocorrendo. Então fique ligado e continue seguindo.

Tenho observado os principais acontecimentos na área de segurança da informação e ainda me pasma ver como empresas gigantes estão sendo afetadas por ataques dos mais variados tipos e ao analisar o caso com calma, (depois de enxurradas de especulação) a gente se depara com fatos que não admite, mas, que são o “calcanhar de Aquiles” das empresas –  processos, estratégia, arquitetura e cultura de boas práticas.

Estou aqui chamando grandes nomes do mercado (como CIO e CISO da Equifax, por exemplo) de incompetentes? De forma alguma, são profissionais de alto gabarito que não conseguem fazer tudo sozinhos e em algum momento seus comandados deixaram algo no meio do caminho e como consequência o cargo mais alto, mais exposto na mídia acaba pagando o preço e se e alguns casos é possível achar o foco do problema e possíveis culpados, em outros o posto mais alto assume o prejuízo.

Mas porque casos como estes ocorrem? Obviamente estamos lidando com pessoas que têm a seu dispor um vasto conhecimento não só técnico, mas acima de tudo em engenharia social e por mais que seus métodos estejam ultrapassados ou a “qualidade do golpe” (palavra meio gasta nos dias atuais) não seja das melhores, muitos ainda caem de forma primária.

OK… a culpa é só do individuo que clicou no link que não deveria ou abriu o arquivo que veio atachado em um email? Não colega…a culpa é sua também, pois em muitos casos o usuário final não tem seu conhecimento e é por isso que você precisa implementar em sua empresa um programa de segurança da informação. Você tem o conhecimento, o usuário não (conhecimento técnico).

Vamos imaginar que o mundo está o caos (e está mesmo). Mas existe um lugar em que se pode manter as vitimas do caos a salvo. Uma fortaleza com muros de concreto, portas de aço onde nada, nem ninguém pode penetrar sem autorização. Milhões e milhões foram gastos para construir essa fortaleza “impenetrável”. Você e todas as vitimas do caos estão seguros neste fortaleza. A sensação de segurança é tamanha que você passa a viver mais relaxado e se preocupa com outras coisas. De repente o caos entra na fortaleza e toma conta de tudo, fazendo daquele que foi o lugar mais seguro do mundo se tornar parte do caos externo. O que aconteceu? Um lugar blindado, altamente vigiado, com portas de aço… como pôde have algo assim? Aí vc analisar todo o contexto do lugar e percebe que havia uma frestinha na canto da parede pela qual adentrou aquilo que você gastou milhões pra se proteger e manter longe do seu ambiente.

Pode ser que isto possa ter ocorrido em sua empresa. Você pode ter os melhores equipamentos, os melhores profissionais técnicos, mas, sem processos definidos, sem definições de responsabilidades, sem análise de ambientes e suas criticidades, você se enquadra no caso citado acima.

Como seu ambiente está montado? Você tem noção do que vai e vem por sua rede? Seus servidores e estações são instalados de acordo com as melhores práticas?

Nas palestras que falo sobre Segurança em Plataforma Microsoft priorizo antes de mais nada a parte de estratégia e arquitetura do ambiente, pois é ali que tudo começa…é na concepção do mesmo que você pode (ou não) ter sucesso.

Você documenta seus processos, seu ambiente como um todo? Tem definido que é responsável por o que? Existe em sua empresa um programa de conscientização de funcionários? Como funciona os acessos físicos e lógicos?

Pois é meu amigo… essas e outras muitas perguntas precisam ser colocadas na mesa por sua área de segurança, de preferência de forma preventiva… antes que um ataque sobrevenha e você não esteja preparado pra ele.

No próximo post vou colocar situações em métodos simples que possibilitarão a você implementar um bom programa de segurança da informação em sua empresa.

Lembrando que Segurança da Informação não é TI… envolve toda empresa e seu negócio principal e você é pessoa que deve convencer a direção da empresa de que é melhor investir em prevenção do que gastar muito mais com remediação e, em muitos casos se perde credibilidade… ou que não tem grana alguma no mundo que resgate.

Nos vemos no próximo volume desta nova série!

Abraços

Uilson

Anúncios
Categorias:Não categorizado

Sobre Azure Web Application Firewall–escrito por Diogo Bacelar

21 de agosto de 2017 Deixe um comentário

Saudações,

Hoje começamos uma nova fase no blog Microsoft Space. Firmo uma parceria (que espero ser vitalícia) com um cara ao qual devo muito pela ajuda que me dá com seu conhecimento e pela pessoa que é. Trata-se do Arquiteto de Soluções Diogo Bacelar, expert em Azure e infra estrutura Microsoft, VMWare entre outros.

Iremos começar a partir deste post, com um trabalho voltado a OWASP (Open Web Application Security Project) voltado a Azure Web Application Firewall. Abaixo o texto escrito por ele que é o primeiro de muitos que teremos aqui neste espaço.

Aos seguidores e leitores deste blog, peço que aguardem, pois estaremos também alterando o nome do mesmo.

Fiquem com o texto abaixo do Diogo e aprendam muito com ele:

Fala pessoALL, tudo bem?

Sou o Diogo Bacelar e é com muito prazer que público pela primeira vez no blog do meu grande amigo Uilson Souza. Vim aqui para falar um pouquinho de uma tecnologia incrível, capaz de proteger nossos ambientes de servidores web e garantir um final de semana sossegado para nós administradores de TI.

Antes de mais nada vamos falar um pouco sobre o OWASP (Open Web Application Security Project/Projeto Aberto de Segurança em Aplicações Web), uma comunidade online que cria e disponibiliza de forma gratuita artigos, metodologias, documentações, ferramentas e tecnologias no campo da segurança de aplicações web. Legal não? Mas se eu te contar que os mais importantes players da área de segurança tomam seus padrões como referência para segurança em ambientes de webservers? Isso mesmo, mestres como PaloAlto, Barracuda, Check Point entre muitos outros usam esta base para seus produtos, padrões estes que você pode ser conferido no portal abaixo:

https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

Já que falamos da referência de proteção quando se trata de servidores web, chegou a hora de explicar um pouco sobre o funcionamento de um Web Application Firewall ou WAF para os mais íntimos (eu amo esta sigla!) . Como você pode ver na topologia abaixo o WAF atua basicamente como um intermediador de todas as requisições que chegam para seu backend de servidores web e pode ser implementado de diversas formas, inclusive como serviço interno(Plugin) em seu próprio webserver.

image

Fonte da Imagem: researchgate.net (acesso em 19 de Agosto de 2017)

O funcionamento e modo em que o WAF irá operar, você quem determina. Ele pode ser Detectivo, que é quando o mesmo atua apenas monitorando todas requisições e às documentando em relatórios. Neste modo você não previne os ataques, mas fica ciente deles, podendo ou não executar alguma ação para preveni-los. Ou pode ser Preventivo, que é quando ele atua incisivamente em todas as ocorrências que venham acontecer em seu ambiente, por exemplo as que fazem parte do grupo de proteção padrão REQUEST-912-DOS-PROTECTION que foca nos ataques do tipo DOS, neste caso se o WAF identificar anomalias na conexão que se adequam a uma das regras que fazem parte deste grupo a conexão será abortada e seu ambiente continuará seguro.

Já que aprendemos como funciona um WAF, chegamos no foco da nossa publicação: O Azure Web Application Firewall. Como o próprio nome diz é um serviço oferecido pela Microsoft para proteção de ambientes de servidores web que estão hospedados em sua plataforma de nuvem pública, o interessante desta oferta é que ela é PaaS(para quem não conhece este conceito aconselho ver este meu webcast gravado aqui https://www.youtube.com/watch?v=rCWluYr3t9U&t=3806s onde abordo de uma forma mais palpável os conceitos básicos de cloud computing) por este fato, você apenas se preocupa em parametrizar o WAF e os servidores de backend que fazem parte da solução, decidir o modo de operação(Detectivo ou Preventivo) e habilitar quais regras OWASP que serão usadas no monitoramento do ambiente. Como é padrão da computação em nuvem, a base deste serviço é toda gerenciada pela Microsoft, isto quer dizer que você não se preocupa com atualizações de Kernel, Segurança, Novos padrões de regras e demais detalhes. O legal é o poder e magnitude que a ferramenta possui, seu custo tem uma média de 150US$/Mês para proteger seu ambiente de diversos tipos de ameaças como por exemplo:

· Proteção contra SQL Injection;

· Proteção contra Cross site scripting;

· Proteção Contra Ataques Comuns da Web, como a injeção de comandos, as solicitações HTTP indesejadas, a divisão de resposta HTTP e o ataque de inclusão de arquivo remoto;

· Proteção contra violações de protocolo HTTP;

· Proteção contra anomalias de protocolo HTTP, como ausência de host de agente do usuário e de cabeçalhos de aceitação;

· Prevenção contra bots, rastreadores e scanners;

· Detecção de problemas comuns de configuração de aplicativo (por exemplo, Apache, IIS etc.).

Ressaltando o último tópico acima, imagina você ter aquele ambiente super bem configurado e homologado (SQN) que permite até ratos entrarem no server, e simplesmente ele estar protegido por este super segurança na porta da grande festa? É disso que estamos falando meus amigos, este é o Azure WAF.

Querem saber e conhecer mais sobre esta possível nova maravilha do mundo? Em breve Uilson Souza e eu estaremos apresentando um webcast com uma recheada demonstração prática deste serviço do Microsoft Azure, fiquem ligados aqui no blog!

Deixem seus comentários, sugestões e elogios, vai ser muito importante para os próximos posts!

Até a próxima!

Diogo Bacelar

image

Sobre DNS Policies–Windows Server 2016–volume 7–Redirecionamento por horário

14 de agosto de 2017 Deixe um comentário

Saudações,

E hoje chegamos ao último volume da série sobre DNS Policies no Windows Server 2016. Para aqueles que ainda não viram, segue abaixo o link para os 6 últimos posts publicados:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

Sobre DNS Policies – Windows Server 2016 – volume 04 – Split Brain DNS e Selective Recursion Control

Sobre DNS Policies – Windows Server 2016 – volume 05 – DNS Filtering

Sobre DNS Policies – Windows Server 2016 – volume 06 – Foresincs

Vamos hoje falar sobre redirecionamento por horário, ou seja, direcionar requisições DNS baseado na hora do dia.

Exemplo – Tenho uma farm de servidores de aplicação com  4 nodes e a partir de hoje, das 16 até as 18 horas terei que parar dois desses nodes para manutenção. Neste caso, as requisições serão encaminhadas somente para os dois nodes que estiverem ligados.

Exemplo 2 – Na minha farm de 4 nodes tenho 2 servidores com mais poder de processamento e os outros 2 têm uma absorção de carga menor. A região atendida pelos servidores de menor processamento irá receber uma carga gigantesca de acessos devido a um determinado evento que irá requerer o suporte a um numero muito maior de acessos aos quais essas máquinas podem receber. Em situações como esta podemos criar uma política em nosso DNS Server para que as requisições sejam direcionados em maior parte aos nodes com maior poder de processamento.

Vamos ilustrar novamente nosso ambiente para este post usando o mesmo de outros volumes desta série:

image

No desenho acima temos os servidores de Fortaleza e Belo Horizonte. Estes equipamentos não têm o mesmo poder de processamento que os alocados em São Paulo e Rio de Janeiro. A empresa promoverá uma ação de marketing que duplicará o numero de requisições por todas as filiais e você nota que CE e BH estão com a performance comprometida. Esta campanha ocorrerá pelos próximios dias das 15 até as 20 horas

Neste mini laboratório, vamos fazer com que o tráfego das subnets de CE e BH sejam direcionados em sua maioria para os servidores de SP e RJ.

Para tanto iremos usar o comando abaixo:

Add-DnsServerQueryResolutionPolicy -Name MktPeakTime -Action ALLOW -ZoneScope ‘SP_ZoneScope,4;RJ_ZoneScope,4;FOR_ZoneScope,1;BH_ZoneScope,1’ –TimeOfDay ‘EQ,15:00-20:00’ -ZoneName uilson.net

No comando acima eu criei uma política chamada “MktPeakTime” que distribuirá a carga das requisições aos servidores de aplicação da seguinte forma:

São Paulo e Rio de Janeiro – 40% cada

Fortaleza e Belo Horizonte- 10% cada

Relembrando – Foi criado um zone scope para cada localidade e o registro DNS de cada servidor criado no escopo da referida localidade. Se você não se lembra como criar escopos de zona, acima deste post você terá os links para os volumes anteriores desta série com o procedimento detalhado.

Quem leu os volmes anteriores desta série também sabe que os numeros definidos ao lado de cada zone escope caracteriza a quantidade de requisições que será enviada a um determinado servidor, por exemplo, no escopo de zona de São Paulo e Rio de Janeiro eu coloquei o valor “4”, ou seja, a cada 10 requisições, 4 irão para SP, 4 irão para o Rio, 1 para CE e 1 para BH. Este processo tb está bem explicado na série.

E assim finalizamos mais uma série de posts neste espaço. A partir de agora, vamos focar em Web Application Firewall do Azure com um post escrito pelo Solution Architect Diogo Bacelar que será postado aqui. Também iremos fazer um webcast em breve sobre este tema. Aguardem.

Espero que o tema possa ajuda-lo em suas tarefas diárias!

Abraços

Uilson

Sobre DNS Policies–Windows Server 2016–volume 06–Foresincs

19 de julho de 2017 Deixe um comentário

Saudações!

Voltamos hoje com o penúltimo post da série sobre DNS Policies no Windows Server 2016 – Foresincs.

A quem está chegando agora, abaixo os links para os outros 5 posts da série:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

Sobre DNS Policies – Windows Server 2016 – volume 04 – Split Brain DNS e Selective Recursion Control

Sobre DNS Policies – Windows Server 2016 – volume 05 – DNS Filtering

Sobre Foresincs temos uma série de termos e metodologias a seguir. No caso de DNS Policies Foresincs, vamos simplesmente trabalhar no conceito SinkHole, ou seja, vamos fazer com que queries para domínios não confiáveis não sejam resolvidas pelo DNS Server.

Temos como bloquear todo o DNS Zone a fim de que não resolva um determinado domínio (vide exemplo abaixo com um domínio fictício chamado “*.malexemplo.com.br”):

Add-DnsServerQueryResolutionPolicy –Name BadDomainBlock -Action IGNORE -FQDN ‘EQ,*.malexemplo.com.br’

Ou podemos definir que registros dentro de um Zone Scope (Escopo de Zona) não resolvam um domínio que possa trazer a infecção de um malware por exemplo:

Add-DnsServerQueryResolutionPolicy –Name BadDomainBlock -Action IGNORE –ZoneScope “BlockedRecords” -FQDN ‘EQ,*.malexemplo.com.br’

Podemos bloquear uma subnet inteira evitando a resolução a partir dos IP´s nela contidos:

Add-DnsServerQueryResolutionPolicy –Name BadDomainBlock -Action IGNORE -ClientSubnet ‘EQ,SubnetSaoPaulo’

Conclusão

Neste post, curto, porém importante, mostrei como usar o conceito de sinkhole para Foresincs via DNS Policies do Windows Server 2016.

Espero que possa ajudá-lo em suas tarefas diárias.

Abraços

Uilson

Categorias:Não categorizado

Petya Ransomware–algumas informações

27 de junho de 2017 Deixe um comentário

Saudações,

Hoje vamos dar um parênteses na série sobre DNS Policies do Windows Server 2016 para falar da onda de ataques massivos iniciada hoje (27/06/2017) na Ucrânia e que se estendeu por outros países da Europa.

image

Trata-se do Petya Ransomware (ou Petwrap), uma variante do WannaCry que também explora vulnerabilidades na porta 445 – protocolo SMB v1.

Um dos casos mais interessantes foi um supermercado na Ucrânia totalmente parado devido ao ocorrido, conforme imagem abaixo:

russia

Algumas informações:

O ocorrido foi noticiado pelo Telegraph e pela BBC nos links abaixo:.

http://www.telegraph.co.uk/news/2017/06/27/ukraine-hit-massive-cyber-attack1/

http://www.bbc.co.uk/news/technology-40416611

Uma das recomendações é se assegurar que o patch MS17-010 está instalado em seu ambiente. Se ainda não o fez e teve a sorte de não ser atacado pelo WannaCry, então não dê sopa ao azar e atualize.

Entre com alugmas ações pro-ativas:

 

1. Além do patch MS17.010, desabilite o protocolo SMBv1 em seu ambiente.

2. Se constatou a falta do patch em algum equipamento, remova-o da sua rede até que o mesmo esteja atualizado

Mais informações:

A brecha do protocolo SMB não é o único meio pelo qual o ataque pode ser executado. A famosa engenharia social tb pode trazer problemas. Portanto conscientize seus usuários da importância de evitar abrir emails com aenxos os quais não saiba a procedência. Abaixo o email associado ao virus:

wowsmith123456@posteo.net

O endereço do BitCoin informado para pagamento do “resgate”:

1Mz7153HMuxXTuR2R1t78mGSdzaAtNbBWX

Cuidado com os IP´s abaixo:

 

84.200.16.242 – porta 80

111.90.139.247 – porta 80

Portas usadas:

TCP 1024-0035, 135, 445.

 

A execução dos arquivos abaixo inicializa a ação do malware:

File Name            Order-20062017.doc       (RTF із CVE-2017-0199)

MD5 Hash Identifier       415FE69BF32634CA98FA07633F4118E1

SHA-1 Hash Identifier     101CC1CB56C407D5B9149F2C3B8523350D23BA84

SHA-256 Hash Identifier                FE2E5D0543B4C8769E401EC216D78A5A3547DFD426FD47E097DF04A5F7D6D206

File Size                6215 bytes

File Type              Rich Text Format data

 

File Name            myguy.xls

MD5 Hash Identifier       0487382A4DAF8EB9660F1C67E30F8B25

SHA-1 Hash Identifier     736752744122A0B5EE4B95DDAD634DD225DC0F73

SHA-256 Hash Identifier                EE29B9C01318A1E23836B949942DB14D4811246FDAE2F41DF9F0DCD922C63BC6

File Size                13893 bytes

File Type              Zip archive data

 

File Name            BCA9D6.exe

MD5 Hash Identifier       A1D5895F85751DFE67D19CCCB51B051A

SHA-1 Hash Identifier     9288FB8E96D419586FC8C595DD95353D48E8A060

SHA-256 Hash Identifier   17DACEDB6F0379A65160D73C0AE3AA1F03465AE75CB6AE754C7DCB3017AF1FBD

File Size                275968 bytes

 

Sugiro que você crie uma política no seu servidor de antivirus bloqueando a execução dos arquivos citados acima.

Maiores informações nos links abaixo:

https://virustotal.com/fr/file/027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745/analysis/

https://www.hybrid-analysis.com/sample/027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745?environmentId=100

No link abaixo a Symantec partilha dicas de como evitar o ataque:

https://www.symantec.com/connect/blogs/petya-ransomware-outbreak-here-s-what-you-need-know

Fique atento e mantenha seu ambiente atualizado. Além disso conscientize seus usuários sobre engenharia social e o perigo de se abrir anexos não conhecidos.

Abraços

Uilson

Sobre DNS Policies–Windows Server 2016–volume 05–DNS Filtering

19 de junho de 2017 2 comentários

Saudações! Depois de atuações em alguns auditorias de cybersecurity estamos aí de novo pra continuidade dessa interessante série de posts falando sobre DNS Policies no Windows Server 2016.

A quem está chegando agora, abaixo os links para os outros 4 posts da série:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

Sobre DNS Policies – Windows Server 2016 – volume 04 – Split Brain DNS e Selective Recursion Control

Hoje, neste 5o. post desta série, vamos falar sobre DNS Filtering, que são filtros de critérios baseados em requisitos definidos na criação da política propriamente dita, ou seja, a resposta de um DNS Server ocorrerá de acordo com a maneira que um cliente faz a query.

Todos os termos associados aos procedimentos de criação de policies podem ser vistos nos posts anteriores desta série, pois, aqui vamos entrar de forma mais dinãmica no que podemos fazer em termos de Filtering via DNS Policies.

1. Bloqueando queries para um domínio:

Você pode impedir que seu DNS resolva requisições para um determinado domínio. Vamos supor que eu não queira que meus usuários acessem nada que seja do domínio *.malicious.org:

Add-DnsServerQueryResolutionPolicy -Name "BlockedDomains" -Action IGNORE -FQDN "EQ,*.malicious.org" –PassThru

No exemplo acima eu criei uma policy chamada “BlockedDomains” que vai ignorar tudo que for igual (EQ) a “malicious.org”.

2. Bloqueando queries para uma subnet:

Vamos agora supor que eu precise bloquear o acesso a uma subnet, ou seja, uma quantidade de endereços os quais eu teria mais trabalho em bloquear um a um:

Add-DnsServerClientSubnet -Name "BlockedSubnet" -IPv4Subnet 129.214.16.0/24 -PassThru

Add-DnsServerQueryResolutionPolicy -Name "BlockedSubnetPolicy" -Action IGNORE -ClientSubnet  "EQ,BlockedSubnet" -PassThru

No pirmeiro comando eu criei uma subnet chamada “BlockedSubNet” onde eu defino a subnet 129.214.16.0/24. No segundo comando eu crio uma regra chamada “BlockedSubnetPolicy” que ignora tudo o que estiver na range de IP citada.

Este filtro pode ser ainda mais incisivo. Vamos supor que eu queira bloquear acessos a tudo que estiver na subnet acima citada que responda pelo domínio *.malicious.org, ou seja, tudo que responder pelo domínio citado e estiver dentro da subnet criada será ignorado:

Add-DnsServerQueryResolutionPolicy -Name "BlockedSubnetPolicy" -Action IGNORE -ClientSubnet  "EQ,BlockedSubnet" –FQDN “EQ,*.malicious.org” -PassThru

3. Bloqueando e liberando tipo de queries

Vamos fazer um mini lab! Eu vou bloquear toda e qualquer consulta a partir do meu DNS Server e depois vou liberando de acordo com a necessidade.

Add-DnsServerQueryResolutionPolicy -Name "BlockAll" -Action IGNORE -QType "EQ,ANY" –PassThru

Cuidado: O comando acima simplesmente bloqueia todo tipo de queries e requisições a seu DNS. Então planeje bem ao usar o parâmtro ANY.

Agora vou fazer a liberação de determinados tipos de queries. O comando abaixo libera queries do tipo A, AAAA, MX, NS e SOA a partir da interface interface interna do meu DNS Server (10.10.1.20):

Add-DnsServerQueryResolutionPolicy -Name "WhiteListQType" -Action IGNORE -QType "NE,A,AAAA,MX,NS,SOA" –ServerInterface “EQ,10.10.1.20” -PassThru

Vamos agora a outros tipos liberação. Vamos liberar as consultas para meu domínio interno:

Add-DnsServerQueryResolutionPolicy -Name "Whitelist" -Action IGNORE -FQDN "NE,*.uilson.net" –PassThru

O comando acima cria uma white list liberando consultas a tudo que vier do domínio uilson.net, usando o parâmetro NE (Not Equal).

Agora vamos liberar o acesso a uma determinada subnet. Vamos repetir alguns parâmetros do comando exibido no item 2 deste post:

Add-DnsServerClientSubnet -Name "WhiteListSubNet" -IPv4Subnet 129.214.16.0/24 -PassThru

Add-DnsServerQueryResolutionPolicy -Name "WhitelistAllowedSubnetPolicy” -Action IGNORE -ClientSubnet  "NE, WhiteListSubNet" –PassThru

Nos comandos acima criei uma subnet chamada WhileListSubnet contendo a range 129.214.16.0/24 que será liberada para consultas DNS a partir da policy WhiteListAllowedSubNetPolicy.

4. Conclusão

Neste post mostrei exemplos de aplicação de filtros a partir do DNS Policies no Windows Server 2016. Como sempre digo aqui, espero que o conteúdo seja útil e possa ajuda-lo em seu dia a dia.

No próxima post da série irei mostrar DNS Policies para foresincs.

Abraços

Uilson

Sobre DNS Policies–Windows Server 2016–volume 04–Split-Brain DNS e Selective Recursion Control

29 de maio de 2017 Deixe um comentário

Saudações,

Peço desculpas pela demora na publicação do quarto volume desta série. Estive em dias de muito trabalho e alguns percalços pessoais. Mas de qualquer forma vamos ao conteúdo de hoje – Split-Brain DNS.

A quem está chegando agora, abaixo os links para os outros 3 posts da série:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

De acordo com a teoria que coloquei no volume 1 desta série, com o recurso de Split-Brain DNS os registros são divididos em diferentes escopos de zona no mesmo servidor DNS. Os clientes DNS recebem uma resposta baseado onde de fato estes clientes estão – internos ou externos. Este recurso pode ser configurado em zonas integradas ao AD ou para DNS Standalone Servers.

Também iremos criar políticas de seletive recursion para mitigação e vulnerabilidades em ambientes como este.

Em tempo – Este laboratório foi criado em meu ambiente tendo como base o laboratório do artigo Split-Brain DNS Deployment Using Windows DNS Server Policies do pessoal do Networking Blog da Microsoft. Como não tinha montado nada semelhante, me espelhei no conteúdo deles para criar o meu. Para aqueles que notarem a semelhança do meu lab com o deles, fica aqui registrado que a idéia inicial é do link citado e deixo a eles o devido crédito.

Vamos então a parte prática!

Imaginemos que tenho um site que deverá ser acessado tanto por usuários internos quanto externos. Esse possui informações de produtos da minha empresa que a equipe compartilha com parceiros externos.

Meu DNS posui duas interfaces, uma interna e outra externa

Interna – IP 10.10.1.100

Externa – IP 200.185.0.55

Meu servidor de aplicação interno responde pelo IP 10.10.1.10 e meu servidor de aplicação externo responde pelo IP 66.56.40.10 (lembrando que estes são IP´s fictícios, os IP´s que usei no laboratório do meu ambiente são outros e aqui fica só para ilustração)

Objetivo – Usuários na minha rede interna, irão acessar o site produtos.uilson.net do back-end Server interno e usuários externos irão acessar o back-end server externo, conforme o desenho abaixo:

 

image

Com o cenário definido, vamos ao procedimento que torna tudo isso real:

Vamos começar criando um zone scope para o acesso interno, ou seja, os acessos que virão pela interface 10.10.1.100:

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “InternalAccess”

Iremos criar o zone scope somente para o acesso interno, ficando o acesso externo direto no zone uilson.net no escopo padrão.

Agora vamos criar criar os registros para os acessos interno e externo, sendo que, para o acesso interno, iremos cria-lo já dentro do zone scope que acabamos de criar:

Registro de acesso externo – Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “produtos” –IPv4Address “66.56.40.10”

Registro de acesso interno – Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “produtos” –IPv4Address “10.10.1.10” –ZoneScope “InternalAccess”

Agora que temos o zone scope e os registros criados, vamos à política que irá diferenciar acessos internos e externos:

Add-DnsServerQueryResolutionPolicy –Name “SplitBrainPolicy” –Action Allow –ServerInterface “eq,10.10.1.100” –ZoneScope “InternalAccess,1” –ZoneName uilson.net

Feito!!!! Temos agora nosso ambiente direcionando as requisições internas ao site produtos.uilson.net para o back-end server interno e os acessos externos indo diretamente para o servidor externo, conforme definido no escopo inicial.

Poderiamos dizer que temos o trabalho finalizado, certo? Errado! Deixar o ambiente simplesmente como está pode, em alguns casos, criar uma vulnerabilidade que precisa ser mitigada.

Lembre-se que neste exemplo temos um DNS Server resolvendo nomes para recursos internos e externos. O que pode ocorrer aqui é que requisições internas e externas passem fazer queries por endereços de internet, podendo expor o ambiente a um Reflection Attack ou DNS Amplification Attack – um DDoS.

Neste caso, as resoluções recursivas para nomes externos precisa ser bloqueada e para isso criaremos outra política que vem a ajudar na mitigação desta vulneravbilidade:

image

Desenho original do link: https://blogs.technet.microsoft.com/networking/2015/05/12/split-brain-dns-deployment-using-windows-dns-server-policies/

O link que postei sobre DDoS DNS Amplification Attack pede que a funcionalidade da recursiva seja desasbilitada no servidor DNS. Neste caso, vamos desabilitar este recurso que será usado somente para requisições internas.

Desabilitando a recursiva: Set-DnsServerRecursionScope –Name . –EnableRecursion $False

No comando acima, a recursiva está sendo desabilitada para o escope default (tudo que está em uilson.net).

Agora vamos habilitar a recursiva somente para um escopo de clientes internos:

Add-DnsServerRecursionScope –Name “RecursionInternalClients” –EnableRecursion $True

Agora vamos criar a política que irá permitir a recursiva somente para clientes internos;

Add-DnsServerQueryResolutionPolicy –Name “SplitBrainRecursionInternal”-Action ALLOW –ApplyOnRecursion –RecursionScope “RecursionInternalClients” –ServerInterfaceIP “EQ,10.10.1.100”

Agora temos nosso ambiente executando dentro de uma melhor prática para o recurso do Split-Brain DNS.

Espero mais uma vez que o conteúdo possa ser útil e não perca o volume 5 desta série. Iremos falar sobre Filtering com DNS Policies.

Abraços

Uilson

%d blogueiros gostam disto: